Line 3 is redundant and should be removed.
Lines 2 and 4 do nothing in the context of PSOS
Lines 12/14/40, if you show all records, nothing else runs, you just show all records, not sure if this is on purpose or if line 40 should be moved to line 16 above the "go to record". I would expect "exit script" here if you didn't want to do anything if there were no found records.
Line 30/31, No reason to use $$variables vs. $single variables, unless you're looking for a value outside of this script.
Swapping lines 8/9 and 21/22 will give you small performance benefits
Also, you're using a special character (#) in one of your field names, another thing to watch out for.
I'd imagine that if after all that it still isn't working, you have some sort of other context that is not available for the server when this is run. Check permissions, and trigger scripts or other things used in the call stack.
to optimize this for PSOS consider that any navigation that does not do anything is not needed when run from server.
Freeze window line 4 and the go to layout at line 3 can be eliminated. Allow user abort line 2 is not possible when PSOS. Show all records at line 13 is not needed.
As far as exactly whats wrong you should explain the indications you are receiving that suggest the script is not performing right.. exactly what do you expect when this script finishes and what are you actually getting?
You light also want to take a look at the relationship between BlackbirdAF and blackbirdAF_contex 2 table occurences
Lines 38 and 39 are also useless
In addition to all of that excellent feed back, check to see if one of these layouts requires that a file automatically open in the back ground if not already open. This might be needed if fields on one of those layouts refer to data from another file. In a client session, this file is opened in the background using the current file's credentials, but this does not happen when run via PSOS.
If that turns out to be the issue, make sure all needed files are open before kicking off the PSOS.
Use the Compatibility button in FileMaker 15 script editor and select Server. This dims any script step not compatible with PSOS. A few years ago I kept crashing while trying to do a PSOS and discovered that this was caused by incompatible script steps. Painfully I had to run the script, crash and delete that line. Now you can see ahead of time what steps are incompatible.
The grey steps here would cause a crash.
Open your script, select the compatibility option to check, and delete those from your script or wrap an if for don't do this on server.
1) Define "it fails".
2) You probably don't need a script to do what I think you're trying to do, just some summary fields;
3) if you like scripts, in this peculiar case some ExecuteSQL's could be great, would avoid all the go to layout you use for establishing context;
4) do you have an opening script that could mess up things ? It will be called when PSOS'ing.
5) you are referencing some unstored values I guess (line 24, line 31), maybe it would be more efficient to do the work where the data is instead of looking at it from far away.
the rest has been covered wonderfully by the other posters.
Mike Beargie wrote:
Check permissions, and trigger scripts or other things used in the call stack.
Just to make that explicit, before your PSOS script begins to run you have, at the very least, to:
Open the File -> triggers OnFirstWindowOpen
Display a Layout -> triggers OnLayoutOpen
Display a Record -> triggers OnRecordOpen
The layout that will be opened is the layout that was open when the file was closed when it was last run locally, ie, not on the server. There is also the "Switch to Layout" option in File Options that can cause another layout to display.
Thanks for the help guys. I'm not sure which change made the difference but it's working now.
I'm pretty sure Phil nailed it.
Yes contrary to even the documentation and all filemaker behavior, PSOS is the only piece of tech in filemaker that can't open needed files itself. It only works if on the PSoS launching client, all needed files and subfiles of the PSoS script are already opened on the calling client.
This explains why sometimes it works and sometimes it doesn't, depending of your invoking client's opened files.
I consider this to be a terrible bug that renders PSoS useless to me, but FMI thinks it's ok while it's not consistent will all the filemaker experience nor the documentation (at least the last time I checked it).
You can voice your legitimate concern here