Jump to content

This topic is 3084 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@ 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?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

 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.  

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

 

Link to comment
Share on other sites

This topic is 3084 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.