Globals Question: Multiuser

[T-Square]

This is something of a technical question, and rather complicated, but here goes:

I have a solution in which I have a central Globals table in my interface file. Most of the solution actively uses this globals file for storing and calculating various results. The Globals table has one "real" data field, and all the rest are globals or calculations.

I set up each global field to auto-enter a default calculation always. I also installed a startup script that deletes all records from the table and then creates a new single record. The combined effect of the default values and the startup script is to initialize every value at startup. This helps me cut down on scripting errors.

I am suddenly wondering what will happen in a multi-user environment. I understand from some previous threads that global variables are client-specific, meaning that two users running simultaneously will have independent sets of global values.

However, I do not know what will happen in my situation. User A logs in, and the startup script deletes all the records and creates a new empty record, which initializes all the globals to their defaults. That user then takes several actions that result in setting some of the globals. Then, user B logs in, and the globals file is emptied and globals are reinitialized. What happens to the first user's values?

I haven't had a chance to explore this, but perhaps others have experience with it and could share that with me?

Cheers,

David

Edited December 14, 2005 by Guest
grammatical

[David McQueen]

I guess the questions are:

A. if all the values are globals and all are set at startup for the user, why is there more than one record?

b. Why are you deleting records?

In a networked scenario, if the globals are set at startup, each user has their own values. No need to have a single record per user if no changes are being made after startup and all is global.

If there are changes being made to fields that are not global, the scenario would most likely be, one record per user to prevent any possiblity of record lock and to preserve the values in the non global fields. In this case, why not create the record as a person logs on and destroy that particular record as they log off.

Alternately, create a series of recrods and have the user log onto a random record with a check to see that it is not already occupied by someone else. Then set his values to the existing record.

I do not see a reason to destroy all records on startup.

Going to your question, when records are destroyed and then a new record is created, the global values will default to the last values entered in a single user scenario where the user was the actual host of the file. In short, when user B logs in, User A's values are destroyed and replaced with the default values as the records are wiped out and a new blank record is created.

so you can expect some problems.

HTH

Dave McQueen

[Genx]

Basically yeah, the solution to your problem is to get the file off server, open it locally on a copy of filemaker, insert all the globals into ONE record, get rid of all your deleting / creating record scripts... then put it back onto server, anything that gets edited by your users will be undone when they reconnect... i.e. all the values will be reset to the ones you specified locally...

Edited December 15, 2005 by Guest

[bruceR]

Basically yeah, the solution to your problem is to get the file off server, open it locally on a copy of filemaker, insert all the globals into ONE record, get rid of all your deleting / creating record scripts... then put it back onto server, anything that gets edited by your users will be undone when they reconnect... i.e. all the values will be reset to the ones you specified locally...

No. The solution is to use a single-record resource table and put the default values into that. Then they persist when the file is closed and opened again.

[T-Square]

Everyone--

Thanks for the feedback. This is what I suspected, and I'll be looking at other means of handling this. Now, to elaborate...

Bruce--

You say "single-record resource table"--that's sort of what I was trying to manage, in my ham-handed way. How do you ensure that your resource table is a single record?

David--

I think the core issue *is* setting all the variables. My globals table is meant only to house global values (and that's all it has), but my experience is that FM globals behave oddly in an empty table. So I have a single record there, and as I got to thinking (I guess THAT'S the problem!) I figured why not clear the table out each time and have the globals reinitialize based on default values? This way, I don't have to make a script with 75 Set Field steps in it, just to be sure that all the values are blanked. It was only after I had implemented it (quite successfully in a single user scenario, I might add), that I started thinking about the multiuser circumstance.

aflgenx--

Thankfully, none of my clients are sharing the db now (FM6 and the odd crash cured them of that--heh, heh!), so I am really just trying to anticipate what would or will happen if I leave things the way they are.

I'm glad I started to think before I deployed, and I am grateful for the feedback!

David

[Genx]

Bruce... dont globals persist after a file has been opened and closed anyway.. no matter what the users do to them...?

[David McQueen]

Bruce... dont globals persist after a file has been opened and closed anyway.. no matter what the users do to them...?

In a single user scenario - yes

On a network, the last values entered in the globals when they were entered by the host of the files (either the person hosting the files in a peer to peer network scenario or the last person using the files in a single user scenario) are persistant.

It comes down in many cases to what value4s do you want to stick and arranging to enter them so that they will stick in a served situation.

the alternative is to have the global values set at startup.

Dave McQueen

[bruceR]

Everyone--

Bruce--

You say "single-record resource table"--that's sort of what I was trying to manage, in my ham-handed way. How do you ensure that your resource table is a single record?

You use a startup script like this: (pseudocode)

Go to layout for resource table

Show all records

Unsort

If record count > 1

Go to record 1

omit record

delete all records

end if