1 of 1 people found this helpful
Regarding global fields... when hosted by FileMaker Server (such as at Datatrium), global fields can still be used. The only 'limitation,' is that 1) a global field stores data independently for each user concurrently sharing a database, meaning the same global field may contain different values for each user; 2) the content of a global field, when a user first logs in, is always what the value was at the time the un-hosted file was last closed by FileMaker Pro / Pro Advanced. When this same file is hosted b FM Server, ay value put into the global field by any user is lost and effectively reset to this default any time a user logs in.
This means you can't use globals for things like settings and preferences that you plan to change occasionally while hosted on the server. You would need to un-host the file, open it with FM Pro / Advanced, change the globals, then re-host the database with the new global values (new defaults).
I hope that explains the distinction with some clarity.
Thanks for the explanation, Erik!
So you think the Datatrium type hosting service is a fine way to go for us?
We like it, I just want to make sure I'm not missing something obvious about some other way that would provide better functionality.
There would be no different functionality elsewhere, so if you're happy with the service, stay with Datatrium.
If you need to change how the database functions, that can still be done. I've only presumed how and why you're using globals and why there's suddenly a global field probelm with the files being hosted. Are you able to explain further what you need the database to do that you've tried with globals? There may be a viable alternative.
I don't think I need global fields. I was just mentioning one limitation that I knew of (Datatrium told me about it) and wondering if there were others that I didn't know about. But I think you've answered No to that, so I'm happy to stay with Datatrium.
Thanks a lot!
How can they prevent globals from being used?
I believe we can have Global fields that are user specific but not the same for the entire database.
That seems congrous with the way you explianed it, right?
You are correct that global fields are user specific but you can use global fields for system wide data shared by all users. In all my systems there is a one record 'settings' or 'preferences' table. Stored data is loaded into global fields on startup
The fields consist of standard fields with matching global fields. One example could be a company logo.
SystemUI_Logo [ container ]
gSystemUI_Logo [global, auto-enter calculation replaces existing value] = Case ( gGlobalSettingsTrigger ; zSystemUI_Logo ) instead of physically setting each global I trigger the update by setting gGlobalSettingsTrigger to 1. Then gSystemUI_Logo can be put on all layouts to display the company logo.
On startup the values stored in the regular fields are loaded into global field for each user. They all get the same value. I also use Icon repeating field with matching global repeating field. I store various icons that are used throughout the system. Here you have to set each repetition. I haven't found a way to update with a trigger.
However, with the advent of variables I have substituted variable for some of the global fields i used to use.
Pueblo Systems, Inc.