Hi

We have a solution which contains various global fields used to store preference data.

However as the solution is hosted with FM Server a client who access the solution is unable to edit these fields. Only the host is able to do this.

This is a real pain as in order to make a change to a global field in the preferences area of the sloution you have to close down FM server, re-launch the solution with FM pro, make the changes, quit FM pro and then restart FM server.

Does any one know of a trick or work around that will allow a client to force a change to a global filed?

You need a Globals table with a single record. For each global you want to set, create a non-global field in the table. In your start up script, go to a layout based on the Globals table, and Set Field the globals to their non-global counterparts.

If you set up those non-global preference fields in your Users table, you can have preferences specific to each user.

Thanks for the tip.

I presume that the start-up script can’t be executed remotely by the client and that you will have to restart the solution on the server.

Nope. The start up script will run when the client opens and load the globals just fine. Any client with access to the table can change the field, but that change won't come into effect until the script is run again.

This is an old thread, I know, but if you're still subscribed, D J, can you tell me whether it is possible to implement this using two tables (one non-global, one local) rather than one? The two tables would have identical fields and could, I assume, be connected in the relationships graph by a Cartesian join.

Would there be any drawbacks to a two table solution? If so, how do you deal with naming the fields? Just, say, add the word "global" to each global field? This strikes me as slightly less elegant than the two-table solution, but maybe I'm not anticipating a problem.

Thanks,

Jerry

DJ's terminology might need some explaining. Tables themselves cannot be "global" in the same way that "global fields" can be defined.

What he refers to is what some people call a "preferences" table, which consists of a single record with "normal" fields in it to hold data. This table can be related to all others tables via cartesian joins so the data in the fields is accessible, but this produces a lot of table occurrences in the file and is a lot of work. An easier method is to create a corresponding global field for each normal data field, because global fields can be accessed from any table even unrelated ones.

The down-side to the use of global fields is that their values need to be populated somehow (because global fields have weird super-powers) and this is done with a startup script.

Ive rarely read a more well phrased explanation. Thanks for that!