Planning for shared access

[Thomas An]

Hi all,

After laying out the foundation for a database, I caught myself encoding some layout interface functions into scripts and the scripts were using global variables to store the status of a layout (toggle buttons ... and the like).

... however, on second thought ... isn't this a bad idea ?

For example, if we have two users signing in as guests and one of them makes a change (presses a toggle), then the other will be seeing those layout changes happening to his screen all by magic. No ?

So, here I am, back to the drawing board trying to design (or simplify) the UI and avoid use of global variables for the UI.

Your thoughts on this ?

[IdealData]

Globals only affect the client that is modifying them, so the other users will not see the same changes.

Construct a simple test first to prove it.

[Thomas An]

You are right ! ... now, as I test this, the globals are not being affected.

Interesting !

Thank you for pointing this out.

This is a pleasant surprise, but I am also confused a little ...I thought that globals are part of the table data and the table data are (should be) visible to all.

[IdealData]

Globals are part of the field definitions and previous versions of FMP explained their existence differently. You can think of globals as "user" fields and they retain their values on the client computer.

Globals keep their values when the host saves the file, but clients cannot change the original values. If you wanted a global to always hold the value 1 at start-up then you would open the file as single user, set the global and then save the file. If you host the file on FMServer then every user starts with a "1" and gets their own copy.

Beware when cloning as you can easily lose the original values.