This morning a scripted process for invoicing forty customers for their regular monthly shipment of product X, failed when a scripted find for customers registered for that "Club" failed. The field being searched was a calculated count of the number registered. It is in a scripted triggered whenever we open the layout which lists all clubs we have ever run. The script sets ">0" into the count field and returned an error 401 for which we've never needed to trap.
I then opened a recent backed up copy of the file locally. It failed to generate the same error so we replaced the served file with the backup. The OnLayoutEnter script again failed on the served file. Replacing the layout in the served file with all objects copied from the local version did not prevent the error, nor did copying and replacing the script.
The file and the script in question were created years ago in .fp7 files. They were converted for Version 12 and have been in use for years without ever seeing this particular error. We are currently running FMS v15 on OS X 10.10.5 with FMP v15 on OS X 10.11.6. It is two weeks since we upgraded to FMS V15 and FMP v15. The script has not displayed this error when run most days during the interim.
Running DDRs from the local and hosted version of the file failed to show any diagnostically meaningful difference when loaded into the Difference version of FMPerception.
After finishing work for the day, I closed all files on the sever, stopped the database server, then restarted it, opened the files and ran the script which had failed earlier. This time it failed to generate the error. Yippee!! But why??
My conclusion is that the find was run on the server when the file was hosted. That would be expected as it was on a field with an unstored calculation. Have I unwittingly uncovered a vulnerability in FMS V15??