Ok, the following seemed odd to me, but it may not be for you experienced users.

I just started sharing my first solution with two users using Filemaker Pro 9.0. It seems that I cannot change the date in one of my global fields when two people are logged in to the solution. Every time I change the date in this field, then the date would revert to the previous entry when I logged off and logged back in. This pattern held true even when I made sure the changed record was committed by switching to another record. I also made certain that the other user was not changing back this particular date.

Is this the way it is supposed to work? Or might the culprit be a corrupt file or poorly designed solution.

My goal is a field that stores the same thing across all records. I.e., my solution is structured such that I have a parent table of all my patients (i.e., each record is a different patient) and I have a related table of every time I have an encounter with a patient. The field in question is simply to store the last date that a ledger was submitted to my billing person as a reminder to myself.

Edited November 16, 200718 yr by Guest

Are you running FM Server 9? If you are:

Globals do behave differantly loacally than they do when hosted. When a file is hosted the defualt value for a global field is the value it had when it was hosted, every user can enter thier own value into the global field but when they close filemaker and reopen it, it does revert to the defualt value. In order to change the default value the file must be opened locally and changed, then rehosted.

If you are using peer-to-peer sharing I am unsure of the behavior of globals, I'm sure someone here can tell you what it is.(or at least point you to the right document, I found FM's help file on the subject lacking.)

I'm using FM 9 Advanced (not the server version). I am sharing via peer-to-peer ("FileMaker Network" under my sharing options).

The best way would be I believe is to set up a table and hold all of your values there and then point your global fields to that table.

For example if you have a date that has to be same throughout your solution on all records and for all users you would probably use a global field however global fields do behave as described above so to avoid that problem you make a table like a constant table and then point your global field to the value in the table, like a preference table.

*** always ask for second opinion before taking my advice :)

Just now returning to this dilemma (sorry for the delay). So I tried pointing my global fields to a duplicate table via a script. The fields are not global in the duplicate table and it has only one record. However, the globals only come up blank. To add to my confusion, it worked the second time I ran this script and no time thereafter.

Any ideas or an example that I can look at?

Ok, I just found the answer to this question in another thread...

http://www.fmforums.com/forum/showtopic.php?tid/192389/