From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer
There is a potential problem with the use of global fields (fields with the storage option of global set) in multi-user solutions. Global fields are designed to have the same information on each record. So that is to say if you change the contents of a global field in one record, you have made that change on all the records. There are a number of unique ways you can implement a global field in a layout, calculation, relationship or script. All of these uses can change when the solution goes from a single user setup to a multi-user setup.
What happens is that a change to the data inside of a global field, in a hosted database, only affects the records for that particular user. A common term for this effect is that the change is session specific. Anyone else using the database at that time will see the information that was in that global when they first opened the file. Also, the change of information in that global field will be temporary and will not stay with the user when they close the hosted file. Back to the user that changed the information in a global ... if they close the file and reopen it ... the global will contain the original information.
To make matters a little more complicate, the global field can change its behavior based upon how the file is being hosted. A FileMaker file can be hosted via FileMaker Server or Peer To Peer. If the solution is run on a machine that is using the workstation version of FileMaker (commonly referred to a peer to peer), a global field can operate in 3 different ways based upon ...
1) if the solution is on a machine that hosts the solution ... but ... no other users have signed on yet.
In this case, when the host user makes a change to a global, it is going to stick. From that point forward, that will be the reference information for that global when new people open the database file.
2) if the user is on a machine that host the solution ... and ... the host makes the change to the global field
In this case, when the host user makes a change to a global, it is going to stick. From that point forward, that will be the reference information for that global when new people open the database file. If a guest is logged in when the host changes the global, the guest will not see the edited information until they log off the database file and then log back in.
3) if the solution is on a machine that hosts the solution ... and ... a guest makes the change to the global field
In this case, the changed information inside of the global field will only be seen by that particular guest user during the time they have that file opened. If they close and reopen the file, the data inside of the global will revert back to it’s original content.
The most common way that a FileMaker file will be hosted, is via the FileMaker Server. This means that anyone that logs into the solution will be a guest. The information that is in a global field when the server opens the solutions becomes the default for all guests. The only way to change the default information in a global is to close it from the server, open it with a workstation version of FileMaker, change the information in the global, close the file and reopen the FileMaker file with the server version.
When a FileMaker file is being hosted via the server and data is added to any global field, the information will be for that user only and valid during that session. This can be a very good thing because the global can act like a variable to control script branching, build primary keys in relationships and even control screen display.
** Please note that many developers do not use global fields this way any longer with the ability to set variables using a script or calculation. **
Counters that use global fields will not work in multi-user FileMaker environments. This is because each users changes to a global fields in a multi-user environment will not be seen by the other user. So one users increment from 787 to 788 will not be seen by the other users. To them, it will still say 787. You will likely want to use some sort of self relationship ( with a script that sets a field equal to itself plus 1) when trying to build a counter for multi-user environments.
In Summary ... the multi-user global field issue isn’t really an issue. It is more of a behavior. You can use it to your advantage and you can easily fix any problems that arise.
More info about the author and FileMaker in general, contact me at email@example.com.
© 2008 - 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.