Looks good to me and I do use the newPerformScriptCommand
I'm wondering if it's possible that the script IS running but not working as expected. How are you determining that the script has not run? Does it add/modify records? Maybe try a simpler script first that just adds a record.
not being crtical, just how I would fix this:
don't call a script from php, perform the same steps in PHP. everything is there to do so.
Thanks Jason. The script is listed in my question. It's a dummy script that writes the current time to a text field. As I mentioned it works from FMP client, as PSOS, and when scheduled on the server. Just not when I call it from PHP. I know the API is being called becasue when I give an invalid parameter I get an error.
I'm looking into my server configuration. Seems that FileMaker.php and it's related directory may not be where it is expected. But even so, how would the other API calls work?
So strange ...
Hi Beverly - yes I am aware of that and generally do exactly that, but sometimes it's easier to use a FMP script for development because of the debugger and ability to see what is happening ... and at this point I stubbornly just want it to work!
I don't think the location of the API package matters. The advantage of the intended location, I believe, is that it does not have to be in the same directory as the calling file for "require_once 'FileMaker.php';" to work.
Sorry, I forgot the script was there when I was writing my answer! I would still suggest trying a script that is simply "New Record", just to try to further rule out anything related to the script.
You said "when I give an invalid parameter I get an error."... that's interesting... what is the error? It looks like the parameter is what you're searching for in the Perform Find [Restore]? But how are you getting the parameter into the find request?
Location matters! if...
1. you have already PHP up and running and use the "FM_API_for_PHP_Standalone" - you may need to specify where this is located
You might, perhaps, have a Web Server that is not the same as your FMServer.
2. you let installation add PHP and the API files, then you need not add the path.
but I don't think OP is having any difficulties with "where".
Yeah, I just meant it doesn't matter whether it's "1" or "2". As long as it's included somehow.
1 of 1 people found this helpful
If everything works but scripts do not run I would suggest that the user's privilege set does not allow that script to run.
Found the issue ... after setting up new Server hosted database. The database I had been working on was a mySQL database accessed by ESS/ODBC – a variable I had neglected to describe. I'm still not sure why the FM script originally worked when called by client but not when executed by the Server (PSOS originally worked, but later stopped working, API did not work). That led me to check all of the ODBC settings (Database Manager, Share, and Security permissions).
Ultimately, I think it was an interaction of the validation settings imposed by mySQL and those set by FileMaker.
On the mySQL side of things I allowed NULL and did not set any fields except the key as required. For the FM database definitions I learned that FM validations are above and beyond what ESS sends over when synching in the Database Manager. I set all FM validations to have Not Empty unchecked and set Required On Data Entry instead of Always. I noted that mySQL had passed along its text field length constraints and those were uneditable - which is fine.
Whalaa ... API script calling works.
FWIW, when I set the validation back to Always I cannot get it to error again. So I have some uncertainty but it works now and I must move on.
Thanks for the update!
a variable I had neglected to describe
perhaps your next question won't leave out these variables?
and it's PHP, I would have recommended the MySQL-PHP capablities, instead of ESS to FileMaker and calling with the API.
but that's me!