Global Fields in Multi User Applications

[markpro]

When working in a multi user application, does each user maintain their own value in a global field, or does the last value set by any user become the default for all?

[katiamp]

It depends. Yes, only if the user in question was the one to originally open the database, thus becoming the host. Now, if you're using FileMaker Server or if the host machine is only serving the files, not being directly used by anyone, then the answer is no.

Global fields value changes are kept local and the only changes saved to the database are the ones made locally, by a user on the host machine. Take a look at the FileMaker Help, under the items "Defining Global Fields" and "About sharing files on a local area network".

[BobWeaver]

I've done the same thing in a number of my solutions. I think this is a fairly standard method. It also works well when you are using a script to transfer data from fields in one file to another file. It's much cleaner than multiple copy/paste operations.

[markpro]

Thanks for your reply. To get around this irritation I have created a "Clipboard" file which contains only one record. The fields I needed in my app as global fields (i.e. Inventory Cut off Date) I created as regular fields as opposed to global fields, so that any user could modify its contents. Seems to work well. Does anybody have any other experiences or suggestions?

[DykstrL]

Global fields can also contain initial default data. If a file is opened as a signle user file, the globals will retain the values entered when the file is closed - unless those values are cleared via scripts. If the file is shared as multi-user by a host machine, the globals will still keep the last values entered by the user on the host machine.

If that same file is placed on a FMP server, those initial values will stay and always be the initial values whenever a guest opens the file on the server. So if you do NOT want initial global values on a server-hosted file, you would need to clear all the globals before placing the file on the server to host.

Open scripts can be used to set initial values in globals for the guests which are local and unique for each guest.

Once you get the hang of how global fields behave they can be very powerful and useful in setting up your user's environment and moving data around your files safely, esaily, and consistently.

Thought I'd add my 2 cents.

[LiveOak]

You have hit upon the reason global fields exist. Each user of a FM file has his own copy of a global field (like the found set, or current layout, each user can have a different one). This is what make globals useful for loop counters and temporary variables (gPageCount or gCurrentLayout) and not useful for passing data between users. So, with globals, you don't have to worry about temporary variables in your script getting messed up.

-bd

THIS IS MY 1000TH POST!!!

[rhakka]

excellent and congratulations

[rhakka]

question on this: I frequently make use of global fields during certain kinds of calculations or scripts.

for the sake of arguement, would the program bug out if multiple users on FMP server attempted to run a script that made use of iteratively storing values in a global field at the same time? Or is that something the server program would handle perhaps?

just for the sake of arguement, let's say I had a global field and a script that set it to a field value, then went to the next record to compare that value with the field value in the new record, and did this through every record in the found set. If two users tried to run this script with different found sets... would they both be trying to set the global field with their different values and overriding each other?

[JW]

Congratulations !

And up to the next 10

[JPaul]

Well done,

AHEAD SO ON ....!

[eremaut]

Hi,

There's even more about globals.

Many times i hear people asking, 'can i write to a locked record?'. The general answer is NO.

Well, this is in fact not fully correct. Via scripts you are able to write to the global fields of a locked record (you must 'Set Error Capture [On]' to get this working) and by this i found many times a workaround for the auto-locking(problem) of records by FM. (today, FM 5.5 comes to the rescue with enhanced privileges to dynamically control access to data)

It's even so that you can write to globals in a database without any record!

So, the best way to remember how globals work is to say: GLOBALS are in fact LOCALS (on the client). Compare them to 'variables' as being used in other programs ...

Erwin

[rhakka]

so what's the best way to create a "global" value that is shared among all users of a file?

[Gerd Muller]

In your main db, create a field with the auto value 1. Make a "global"-db with just one record with at least two fields, one with the value "1", the other becomes your "global". Make a relation with the two "one"-fields, so every record in your main db relates to the one and only record in your "global"-db.

Now you can set your "global" to any value with setfield(globaldb::globalfield, value).

Have fun

Gerd