pc server side script not waiting for a calculation before continuing script

[happymac]

I have a script that 

 

1) loads a layout and on that layout there are a series of calculations that take a few minutes to calc.

2) it them exports that data to a CSV

 

The script runs fine on a workstation (filemaker Pro 12), but when running on the server (server 12) it doesn't complete.  It actually does run the scripts successfully, but no data is exported.  

 

After much troubleshooting, I think the problem is that the server is not waiting for the calculations to load before it goes on to the next step.  as an example, on the workstation the process takes about 20 minutes to complete, yet on the server the script is over in about 15 seconds.

 

Is there a way to force the server to wait for the calculations to complete before continuing with the next script step?

[Steven H. Blackwell]

The most likely cause of this is that FMS does not have permissions to export the data to where you wan to send it.  There are approved locations where FMS can export, usually its own data folder or temp file.

 

Steven

[happymac]

Hi Steven.  thank you for the reply.  It is sending to the TEMP file.  As a test, I actually removed the export function and it still is not working ... the issue seems to be that it is not waiting for the calculations to complete, it loads a layout that has a script trigger that through a relationship displays a number of calculated values.  The system is not waiting for these calcs to complete before it proceeds past it.

 

I did find a similar issue here:

http://www.soliantconsulting.com/blog/2013/08/filemaker-plugins-behaving-badly

 

but dont know if someone has created a way to pause the script long enough to get the calculation to complete.  The problem is that I dont want to put in a static pause amount (5 minutes or 10 minutes), because sometime it may take 30 seconds to complete the calcs and other times it may take 20 minutes to complete.  So ideally as described in the url I want to find a way that the pause time can be dynamic.

[Wim Decorte]

Macah's blog post is probably not relevant here, are you using plugins?

 

Since the export is scripted you should probably shy away from calculated fields in the first place and have those fields set through the script prior to exporting.

FileMaker script steps do wait for each other to complete.

[happymac]

actually, ironically the point of the script is to take data from calculated fields into static number fields ... so the users don't have to wait to pull up the reports.  A LOT of thought was put into the system to find the best solution and this is the best solution (IF WE STAY WITH FM), but unless we use a bot computer to run these reports ... I'm having trouble finding a way to get the server to pause correctly.  I really want to push this work off on the server instead of a bot computer if possible.

[Wim Decorte]

There is not much difference between the server-side execution of the script or a bot, except for non-compatible script steps.  So thoroughly vet your script for that (including any on-open scripts that may fire or layout-based script triggers).

 

A "Go to Layout" that has to render a lot of unstored calcs will wait for the layout loading to finish before moving on to the next scripts.  There is nothing in FM scripting that runs on a separate background progress in parallel.

[happymac]

thank you for the reply Wim ... I REALLY appreciate your help!

 

you mentioned "A 'Go to Layout' that has to render a lot of unstored calcs will wait for the layout loading to finish before moving on to the next scripts."

 

Are you sure of this?  That appears to be the issue for me, but maybe i'm wrong.  it looks like when running from the server the system is not waiting to render the unstored calcs and moving on without waiting, while using filemaker pro (a bot) it runs just fine.

 

I have vetted the script thoroughly and looked at the server script steps only ... but maybe i've missed something.  As you know, without logging it is VERY hard to debug...

 

basically the script loads a layout, the performs a few "set fields", then "goto field"  The last field it sets has a script trigger (onobjectexit) that activates to load related values.  If I run the script from filemaker pro the script runs perfectly (but it takes about 5 minutes for the calculations to load, running the same script from the server the script ends (with an OK status) within about 5 seconds and shows zero records were found after loading the script.  either the script trigger is not running OR the server is not waiting long enough for the correct records to load.

[Wim Decorte]

Here's the thing that I don't get:  you run a script for this routine but yet rely on a lot of implicit / indirect behaviour to make it work:

- why not scrap the calculated fields and use explicit "set field" in a script to populate the result?

- why rely on a trigger for the last bit when can you just that script at the right moment in your script?

 

That's the direction that I would take this to.

 

To help you in the short term: do build in some logging in your script to log where you are (layout, record, size of found set, timestamp, error,...) every step of the way.

[happymac]

thank you ... great ideas Wim ... both of which I will implement.  We had a report already made that the users used.  They would plug in a date range and the report would generate (using calculations that were activated by a onobjectexit trigger.  The problem was that this report was taking too long to pull up ... so ...   I 'assumed' (we all know what that means) ... that I could move the script over to the server and have it run once a day ... so the users could look at a non-calculated version.  

 

I can go the longer route (but obviously more reliable) and do what you suggest, just thought i could use what we already had, barring server side limitations.

[happymac]

I wanted to post an update on this ticket as I found the issue and wanted to share it.  Thank you again Wim and Steven for your suggestions, your help is ALWAYS greatly appreciated.

 

Following Wim's advice I removed all subscripts and layoutload script triggers and kept the work within one script.  Testing this, I found the issue was still happening, so I knew from that the issue was not with the server running a script trigger, but rather something further.

 

After some digging, I found that some simple number globals were not being set causing relationships to not work.  When the database opens, I have an opening script that loads these globals via a set field script step, and it looks like the server does not load the "on file open" "opening" scripts when you activate a single script in a server schedule.

 

So, I assUMEd that when running a server side script, the server would act like a user that runs the same script ... and that the opening script would have been run, loading globals into memory, but this obviously did not happen.  

 

Once I added the "set field" script steps to set these globals within the script in question (instead of relying on an opening script), the report ran perfectly from the server.

 

FYI - I was incredibly impressed with the speed of the script running from the server ... takes roughly 3 minutes to load, while a user running the same script takes 10-20 minutes to load.

 

thanks again for your help! 

[Wim Decorte]

 it looks like the server does not load the "on file open" "opening" scripts when you activate a single script in a server schedule.

 

So, I assUMEd that when running a server side script, the server would act like a user that runs the same script ... and that the opening script would have been run, loading globals into memory, but this obviously did not happen.  

 

 

The assumption is correct so there is something wrong with your opening script.

 

To be very clear: any server-side script, whether ran from an CWP query, server-side schedule or PSoS call will ALWAYS run the onOpen script when one is set up.

 

If that script contains any incompatible script steps, it may abort right there and then and never get to your intended script.