I am constructing a small workgroup solution that is hosted on a standalone machine running FMP Server 7, and besides regular "users", I am trying to provide an "administrator" account, such that a particular user in the workgroup can control a certain number of database wide functions (resetting account passwords, close out some tables, etc) without having to use the Server Admin program or access the host machine.

The problem I am having pertains to "globals". I am using globals to track a certain number of database wide varables: some key titles, a "last data release date" etc.

I provided the administrator with a way to change these globals, then discovered of course that the scope of the change is for him and that particular session only. New user login reverts back to whatever globals are stored in the server-copy of the database.

Am I missing something obvious here about the scope and manipulation of user-session globals or must I provide the admin-accessible variables in a linked (1 recor) table (not defined as globals, and then perhaps copy them to the globals on login/startup).

Thanks for your expertise and time.

Cheers,

Justin

Globals don't work that way. A better method for your situation would be to set up a separate table to store key variables, and allow only the Administrator access to the corresponding layout.

I suspected as much. Thanks.

The disadvantage here is that that 1-record admin-variables table has to be linked to any other table that wants to use those "psuedo-globals". Unless I copy them to true global fields (on login?)

You're on the right track, Justin. Just have your opener script copy the contents of the "Global" table to the global fields in the related table(s).

Since you are using v7, and all tables have access to all globals in the file, you can just have a duplicate set of fields in your gloabl table - one set as regular fields - and one set as globals. Your opener script would copy the contents of the regular fields to the global set. Then just access the global set from the other tables.

Share the "global" records in the global table!

That makes table-conscious sense.

Thanks lads.