Global variables are 'per user'. Every user has her own set of global variables - per definition. Therfore, it's not possible to fill globals while running on FMServer for all users.
- You can fill globals using a startup-script
- You can define those globals while running the DB locally and upload it to the server afterwards
That's true - but what if a user has a different requirement to that which I foresee as programmer - which in this instance is highly likely? The only way to change the values is either for them to ask me to do so in the hard-coding, or for me to do so by uploading a new copy to the server. Neither solution resolves the problem as it requires a programmers' input. The whole point as I see it is to produce a robust application that doesn't require later input as users can adapt it to suit their needs - but in this instance it appears that's only the case if it's running locally as opposed to via a server.
There must be a solution - I just can't see what it is!
You can create a user-table (or 'globals'-table) with a record per user where user-settings are stored in regular fields, not globals. A login-script can locate the specific user-record an copy all necessary info into globals (or copy the entries from the globals-table..). Maybe there are other methods as well - without those globals
Besides of this, I'm happy that globals are theway they are...
Sorted thanks; used a "normal" field for the data with a startup script to copy them into global values and a layout script to always show the first record for editing and no status bar.
It is possible for someone to create a second record, if they try hard and use keyboard shortcuts etc, but if they do it is ignored on startup as only the data from the first record is ever copied into the global values. It'll do for now!