Perform Script on Server

[bleapy]

I have a fairly decent size FMdb; everything seems to be working as I want it, as far as calculating and presenting the information I want. However, it's really slow on generating Summary Reports when I'm connected to it on a WAN, or on a FMGo. The reports has a lot of calculation fields; Some values are ExcuteSQL for some Dynamic value changes, and some are TO related calculations.  I wanted to try the Perform Script on Server, but I can not wrap my head on how to get started.  The reports I'm running, is basically doing a Find and Sort.  I don't understand how the Get(Result)?? to get the found and sorted information to the Layout I want to display. Any help/resource would be great. 

Thanks.

 

[OlgerDiekstra]

As the name implies, the "Perform Script on Server" runs on the server, hence the results of the find are available on the server too. Get(ScriptResults) (I'm assuming thats what you mean with Get(Results)) gets the return value of a subscript that was run on the same client. Which means you can't use it as you are intending.

A find is constrained to the client it is performed on. 

An option might be to use snapshots: http://www.filemaker.com/help/12/fmp/html/import_export.17.5.html, though that is probably not ideal.

[Kris M]

More to the point.. find, sorts, and non committed data changes affect only the server session that is invoked when you run a script on server (PSOS).

For your results to affect your session you have to change and commit data or pass the results of PSOS out of the script...

 

 

[bleapy]

Thanks for the responses. I understand that the script will be processed on the Server. However, I thought the result can be passed on to the client once the process is completed? @ Kris, when you say "pass the results of PSOS out of the script..." what can be passed out of the script? a string of records? or just a value?

@ Both ... In my situation, would it be possible to run a PSoS to create a find, and export to a new table, and once completed, the client user's will go to a defined layout to display the result of that new table?  I guess this would cause another issue, if multiple users are running the same report with different variable.  Any suggestions on how to tackle this problem?

 

Thanks.

[OlgerDiekstra]

@ Both ... In my situation, would it be possible to run a PSoS to create a find, and export to a new table, and once completed, the client user's will go to a defined layout to display the result of that new table?  I guess this would cause another issue, if multiple users are running the same report with different variable.  Any suggestions on how to tackle this problem?

Yes, that's possible. You could import the results into another table. To deal with different users, you could add an auto "created by" field, which would capture the user that creates the records. You can then filter that at the users end to only show records they created/found. However, there's a considerable bit of work/resources involved for the server with this, exporting/importing, cleaning up afterwards. And there's the time this might take. If multiple users submit find requests, it might take a while (depending on the number of records found) before a user can continue. What is an acceptable wait time?

[Wim Decorte]

Thanks for the responses. I understand that the script will be processed on the Server. However, I thought the result can be passed on to the client once the process is completed? @ Kris, when you say "pass the results of PSOS out of the script..." what can be passed out of the script? a string of records? or just a value?

 

Anything you can fit into the Exit Script script step as a parameter.  Or anything you can set into a regular field or global field.  So you can pass in enough information to let the user reconstruct a found set for instance but the result of unstored calcs or summary fields will be lost unless you capture those somewhere - like your idea to use a scratch table for the results.

 

[bleapy]

 What is an acceptable wait time?

I don't really have an acceptable time in mind, just something to test out and see which is the best solution.  But at the current speed.. it's deemed too slow to say it can be accessed on FMGO through WAN.  

[David Jondreau]

Add fields that can capture the unstored data in a stored format. Or just use $variables. You'll have your script do PSOS to grab all the calc results and pass that on to the client. Then go to your report layout, do your find and sort, but don't display your performance-killing unstored fields. Instead use the result from the script to populate display globals or variables.

[bleapy]

Add fields that can capture the unstored data in a stored format. Or just use $variables. You'll have your script do PSOS to grab all the calc results and pass that on to the client. Then go to your report layout, do your find and sort, but don't display your performance-killing unstored fields. Instead use the result from the script to populate display globals or variables.

Hi David, wanted to see if I understand what you're suggesting. I would create an extra field to store the "stored" data on the same table? or create a mirror table and copy the entire record to a this Mirror table when that "original" record is being saved/update?

Anyone have a simple example script of doing something similar to this using a PSoS?

Thanks.