Global storage fields not keeping their data and driving me crazy...

[fmow]

I literally input the data, or auto input, see that everything is working well ( i use global fields on an unrelated table to store menu titles, button titles that is is, ui elements etc. ) then I log out of the db (hosted on fms13) and when I log back in everythings blank again...this defies logic...

[bruceR]

No, it does not defy logic.

This is exactly what it is supposed to do.

 

Your expectations are incorrect.

If you want to store preference information, the customary approach is to create a single record preference table for this purpose.

[Wim Decorte]

What Bruce is saying.

 

Global fields, just like global variables are not meant for persistent data storage, their content basically dies at the end of your session.

Global fields can retain a value between session under some circumstances but it is not considered best practice to rely on that.

[Helpful Harry]

Global Fields do save and retain their data ... but only when the database is in single user mode. When the database is hosted, then only changes made by the host user / server are saved when quitting. The individual logged in user changes to Global Fields are not saved when the user Quits (each logged in user actually has their own set of "Global" Fields with initial data copied from the server and any changes lost when the user Quits the database).

If you want to store UI elements in Global Fields, then you need to run the database as a single user first to pre-set the Global Field content, and then Quit and transfer the database to the server or share them.

You also have to be careful with some of the Save As options since they can also delete Global Field data.

[bruceR]

All not guarunteed to be reliable anymore and a waste of time.

[fmow]

Global Fields do save and retain their data ... but only when the database is in single user mode. When the database is hosted, then only changes made by the host user / server are saved when quitting. The individual logged in user changes to Global Fields are not saved when the user Quits (each logged in user actually has their own set of "Global" Fields with initial data copied from the server and any changes lost when the user Quits the database).

If you want to store UI elements in Global Fields, then you need to run the database as a single user first to pre-set the Global Field content, and then Quit and transfer the database to the server or share them.

You also have to be careful with some of the Save As options since they can also delete Global Field data.

 

Hmm, interesting how come? I 've not really used save as that much, and I am very curious as to why it might exhibit this behaviour....

[Helpful Harry]

I haven't got FileMaker on this computer to check, but at least one of the Save As options is to save an empty file (no records), which removes data from all the Fields, including the Global Fields. It's something to be wary of as I found out once when all my UI graphics "suddenly" disappeared from a Save As'ed version. It makes sense from the point of view that you asked for an empty file, so that's exactly what you get. :)

[Rick Whitelaw]

Wait a minute. The ""save as clone (no records)" is not meant to be any kind of working database. It simply saves the basic design of the db. This can be very useful. For example, if you want to know what a user will be confronted with when opening your solution for the first time, an empty clone can illustrate this. I hope I'm not being too obvious or have missed the point here.

[Wim Decorte]

Wait a minute. The ""save as clone (no records)" is not meant to be any kind of working database. It simply saves the basic design of the db. This can be very useful. For example, if you want to know what a user will be confronted with when opening your solution for the first time, an empty clone can illustrate this. I hope I'm not being too obvious or have missed the point here.

 

"Save as (clone)" is also a backup option of an FMS backup schedule and is often done as one more safeguard to make sure you always have a "golden master".  So it could be used to restore and import data in case corruption is suspected.

 

And it is also often used in a solution's "version upgrade" where the development copy is cloned (= very fast way to drop all the data) and then receives a data import from the live system.

 

Either way, all "preset" global data is lost when a file is cloned.

[comment]

save an empty file (no records) ... It's something to be wary of as I found out once when all my UI graphics "suddenly" disappeared from a Save As'ed version.

 

The thing to be wary of is storing values that are considered a part of the schema inside fields - global or otherwise.

[Rick Whitelaw]

All agreed , Wim.

[L-Arnold]

I just ran into this...  Crazy how a global field on a server would not save, but would locally.

I ended up making a Template Database, then running a script to move the Template Data into the Global field.

I tried to work around this by having the fields not be Global, but that was failing.   The Template Load works well and it will allow for other options moving forward - such as the use of different templates for different situations/users.