Is your file now hosted from another computer using FileMaker Pro or FileMaker server?
Changes to global fields made from a client machine do not "stick" when you close the file. To make a change to the global field that will be retained, you must do this from the host machine. If you are hosting from FileMaker Server, this requires either taking the file down off the server to open with FileMaker Pro or running a server scheduled script to modify the value.
In a networked environment, it is sometimes better to put such values in a table that you then related as needed to your other tables with an X operator instead of =. This makes the value globally available, but doesn't use global storage so you can then edit the fields from a client machine if you need to.
Are you working in a hosted file? (FileMaker Server or FileMaker Pro hosted). Because globals are "local user only" values. In a client-server environment all globals will remain only for that session. If you close the file and reopen it, they will have defaulted to whatever their values were when the file was last locally closed.
If this is the case it's time to rethink how you're using globals. Basically, in this situation you should not use globals for values you which to keep between sessions, unless you're willing to reload them via script upon opening (from fixed values).
One way to solve this problem is a Globals (or Constants, or both) one (and only one) record table(s). You can enter a value into a regular text field. Then create a calculation, = text field (that's all, just point it to the regular field). Set the calculation's Storage to Global. You can then use that calculation field as if it was a (non-enterable) global. If you need to change its value, you must change the original regular field. Then wait for it to be refreshed (takes a little while on FileMaker Server, due to caches).
Fenton and Phil,
I did not realize this nor did I think it was the case earlier. I think I originally set up the globals in 8.5. At any rate they are still there.
I do use FM Server 9. I do all of my design work in FMPro9Advanced on a client computer through the server.
So I guess that is where the problem is, eh?
I don't really get why this should be taking place on such an advanced relational database software program.
I'll have to study what was said in both your replies and see if I can understand the theory (correct word?) behind the issue.
Anything further you can add or more detailed steps would be greatly appreciated.
I'm really stumped here... Because - I have about five issues in different databases where the global data is being retained. I must be not understanding something here.
This is actually a very useful feature. Each user gets their own "virtual copy" of any global fields. This way, they can modify the global field contents without their edits colliding with another user's.
You might, for instance, have a search form where the user enters data into global fields for a script to use to search the database. Two different users can enter completely different data into the global fields and neither will see the other's data, nor will data from one user affect the search performed by the other...
Here's a knowledge base article on the subject: http://help.filemaker.com/app/answers/detail/a_id/5895/kw/global%20fields%20network
That does make sense.
I will study all of this more in depth so that I understand a Global field better. I think I'm only thinking about one factor relative to a global field and forgetting about all the perimeter effects.
I have the same problem.
My idea is to load the values of anothers table first record and and with set script trigger on value change in the master table back to the tools table to store it again.
So the read out step was easy
set variable $1 GetNthRecord (tbl2::field ; 1 )
set field tbl1:field $1
But whats the best way to write it back into record on ef table2? I had some complicated
Freeze Window / Go To Layout 2 / Record First / Set Field.... / Go to Layout 1
Is there a faster way?