Search Project Mgmt
Search FileMaker Blogs
« A READER ASKS: Security And The Relationship Graph | Main | A READER ASKS: FileMaker Relationship Graph Documentation »

FILEMAKER: The Separation Model And Run Script With Full Access

From Dwayne Wright - Certified FileMaker 9 Developer
TWITTER: dwaynewright

CHAPTER 09: The Separation Model

This posting was inspired by a series of posts on the FileMaker Tech Talk forum. If you are serious in honing your FileMaker development skills, please consider joining the FileMaker Technical Network and enjoy a wide array of support options like the Tech Talk forum, member only web site access, free software, exclusive learning materials and more. Membership runs just $99.00 a year and I couldn't recommend it enough.

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.

The Separation Model
External Data Source
Manage External Data Sources
Get(PrivilegeSetName) And Scripts With Full Access
The Get(PrivilegeSetName) Function
Substantive Privileges Explored
How Scripts Are Called
FileMaker 9 Server Only Runs Web Compatible Scripts

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.

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

© 2009 - Dwayne Wright -

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.

ADVERTISEMENT ==================
MacUSA provides website and FileMaker Pro hosting services. Utilizing the highest performance web and FileMaker servers. We make FileMaker database hosting as simple as possible. Mac USA Technical Support has been voted the best by our customers. FileMaker Server hosting for your FileMaker web hosting needs supporting FileMaker 10 down through version 5. Hosting FileMaker Pro databases for Instant Web Publishing and Custom Web Publishing including PHP, XML, ODBC, and MySQL access. Use Promo Code dw0904TB for FREE setup (a $25 value) when signing up for your FileMaker Hosting services. Offer expires 6/30/2009.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.