From Dwayne Wright PMP
Certified FileMaker Developer
In a separation module situation, the user interface layouts reside in one file, the actual data resides in another file and external data sources allow the two files to work in unison (with some exceptions). One exception is the ability to run a script with the full access setting due to its dependent nature on where the script resides.
To recap, the "Run script with full access privileges" checkbox on a script is dependent upon actions within the file it resides. Executing a script to delete records within the interface file with "Run script with full access privileges" activated will not override the lack of deletion privileges within the data file for that user.
Run the delete script within the data file and have its "Run script with full access privileges" checkbox selected. The script in the interface file calls upon the data file script and then returns. Depending on the number of records affected (shown within the interface file), the user might see what is going on. Somewhat akin to when Toto pulls back the curtain on the Wizard Of Oz.
Add the ability for the user to delete records in the data file but add conditions that can only occur within a scripted process. This is done by linking the ability to delete to a TRUE calculated result. (add link where I discuss this). The most elegant way to do this is to link the calculation to a global value set by the script, either a global field that can be seen in the data file or setting a global variable within the data file.
REMEMBER: Global variables ... like the "Run script with full access privileges" setting ... are file dependent.
There are a collection of options here that can get pretty messy. One is to temporarily re-login the user with a delete privilege in the data file for the duration of the script. Another option is to NOT delete the script but flag them for deletion. Later on, a user with delete privileges or a batch script (run by FileMaker Server or a robot) actually deletes the record.
ALL METHODS BREAK THE SEPARATION MODEL MYTH
Adding in of the listed options (and likely those that I didn't list) will break the myth that separation model implementations are seamless upgrades. That whatever the coding update to a solution, all you need to do is pop in a new interface file and you are good to go.
In some cases, the developer can go onsite (even virtually) and add the needed schema changes to the LIVE data file. This can be done outside of traditional business hours, after a proper backup has been done. The "bag of hurt" method can be adding the schema choices to an empty data file and the reimporting all the data records again. Both methods have some level of upgrade risk involved and those risks should be measured properly before executing.
More info about the author and FileMaker in general, contact me at firstname.lastname@example.org.
© 2009 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.