The last week I looked myself into this. I read some things on the web about when a calculation is run on the server and not on the client. But it seems like Filemaker 12 runs everything on the client. At least I didn't notice that one of my plugin functions run on the server.
If you get the plugin run on the server, you can use something like our MBS function FM.RunScript to run the script from a calculation.
What happens if you trigger the script with the URL in a browser?
So with your plugin, I will be able to be logged into the client but then run the script that I want to on the server rather than on the client?
I'm sorry, I'm not sure I know how to trigger a script with a URL in a browser. Could you please elaborate? Thanks.
Please specify the FMServer version that you are using.
I am currently using FileMaker Server Advanced version 11, but I will be upgrading to Version 12 very soon. I would like to know if it's possible in either? Thanks.
In FileMaker 11, this works:
As, you can see, it's limited on FMPro.
with FileMaker 12 (combined into one and much more robust:
"Opening shared databases remotely using a URL"
My understanding of the meaning of a "server-side script" is that it is a script triggered by a server schedule, not by a client. So a client machine cannot trigger one. A server administrator can cause a schedule to be run at an unscheduled time by using the admin panel to do it manually, still usign the server interface.
However, FM client software can run that same script via the client software, as long as the user has permissions to read the appropriate disk area where the source file is located, which may be on the FM server machine.
You might even consider just making a duplicate of the script whcih is called by the server, modifying it slightly to be run from the client, specifying a different source file location (the user's desktop?), and have the special user run that script via the client.
Yes, that is exactly what I mean, I want the client to run the script in the database, but not from the client but from the server. I understand what you are saying about giving the client access to the same location but that is not feasible possibility in this case.
I really wanted the client to just be able to trigger the running of the script on the server but from you are saying that is not possible.
Thank you all for your help.
It's somewhat common to schedule a script on the server for every N minutes (less = quicker turnaround, albeit more 'load' on the server) that checks the status of a 'flag' field set by the user - thus executing the desired script steps from the server itself.
An example; we have a server-side script that hourly (9-5, Mon-Fri) checks for the existence of a just such a flag and if it's been toggled by a user it does it's thing (sending out a bunch of status emails).
Message was edited by: mark.stuller Sent via email this post didn't contain the Body?!?
360works RemoteScripter or Trpo Activator can tigger scripts remotely....
I have looked into those plug-ins but they only work if you have a filemaker robot running and I need it to run a script on a FileMaker Server as a service, not as an open application. Unless I'm missing something in their documentation.
One way to accomplish your goal might be to use the following kludge:
Define a field in "parameteres" table (or "settings" table) to be dedicated to client-to-server communication.
Write a script that would run on the client side to set this field to some non-empty value to indicate the server-side script needs to run.
Schedule your server-side script to run every x minutes. (Use whatever interval satisfies your needs.) The server would check the field in the parameters table to see if the client has requested the server-side processing. If the field is empty, just have the server-side script exit. If it is not empty, have the server side script do it's thing. When the server side script finishes the required processing, it would clear the field in the parameters file.
Of course you can get more sophisticated by using a semaphore to prevent simultaneous access to the field in the parameters table by both client and server scripts. You could devote additional fields in the parameters table to pass details from the client to the server script, so the processing on the server side could be customized to handle different kinds of requests or the same request for different reocrds, etc.
Of course this approach doesn't give you immediate results from the server-side processing, but it beats using a robot by a long shot ...
If you are able to turn on XML Custom Web Publishing, you can do this using Insert From URL script step and an XML command to call a script on the server.