Globals vanish!

[wjmartin]

I store a global on a served DB (v7), I use it, occasionally I increment it (add one) - all the while I use it it works fine. Then I log off the server and when I return the global is blank.

Are there some bad pixies hiding in my server room trying to drive me insane or have I missed somthing?

[mr_vodka]

Please take a look at the posting HERE on how globals work.

Please also read the excellent whitepaper that David Kachel has written up. It will explain further.

[wjmartin]

a most excellent response - thanks

unfortunately I wanted to use the global to store a serial number - available to all my users - ie: it occasionally gets incremented (not incremented with every record, only with some) - sounds like a global wont do that!

any other suggestions on how to store a changing global accross several users and sessions?

[Reed]

don't use a global... use a normal field in a table with one record.

[mr_vodka]

Yes as Reed said, you should create one record in a table to store this information. In other words, you can have a new table that only 'stores' information. Then relate this new table to your other tables by the Cartesian operator. ( The 'X' when setting up relationships)

[wjmartin]

the "X - cartesian" reference went straight over my head!

I set it up as described but still no luck - i have defined the realtionship as a simple "=" tho

Edited October 27, 2005 by Guest

[mr_vodka]

Instead of using the '=' sign there is in the pulldown menu, a 'X' symbol. This allows all records from table A to be related to all records in Table B. So after you create this new table, where it holds the fields that everyone can use, have your orignal table relate to the new talbe by 'X' relationship. This way no matter what record a user is on, it will always have access to that stored information in the new table.

[Steven H. Blackwell]

Just to be explicit. Globals are session and user specific. At the end of the session they expire. That's why until the advent of FMP8 we used them. That was their defined purpose: a temporary storage location.

HTH

Steven

[wjmartin]

Excellent guys! it has finally worked!

Many thanks - you guys are great

[xochi]

One thing I don't like about the 'single-record table related with the X operator' solution is the fact that it's really annoying to have this "globals" table related to nearly every other table in my design. It makes the relationships window quite messy.

I've been testing an alternate solution, which is to have a single-record table to hold the globals, but include scripts to set the globals when you open the database, and ones to remember the globals when you exit:

Script "SetGlobals"

Go to layout "Globals"

Show all records // only one record in this table

Set field GlobalValue1 = GlobalValue1.Persistant

Set field GlobalValue2 = GlobalValue2.Persistant

...

Go to layout (original)

Script "SaveGlobals"

Go to layout "Globals"

Show all records // only one record in this table

Set field GlobalValue1.Persistant = GlobalValue1

Set field GlobalValue2.Persistant = GlobalValue2

...

Go to layout (original)

In the "Globals" table, the fields "GlobalValue1" are actual globals, while "GlobalValue1.Persistant" is a regular field.

Advantages:

A1. Since you are using true globals, you can reference these values from every table, without needing to manually relate each table to the global table. Keeps your relationships diagram simpler.

A2. Since you are manually scripting the Set & Save globals functions, you have some control. For example, you could prevent certain users from changing a global permanently, while still allowing them to use it and change it for their session.

Disadvantages:

D1. Requires you to make 2 fields for each global.

D2. You must manually add the fields to the "SetGlobals" and "SaveGlobals" scripts.

D3. Does not save the altered global values if the Client crashes or disconnects abruptly.

Thoughts / Ideas?

[Nicholas Lue]

I'm not sure where to put this script. Can you explain where to put the script and how to run it?

[xochi]

the "SetGlobals" script would be one that you'd want to open each time someone opens the database. I typically create a script called "OpenScript" which I set to run at opening (using "File Options" Open/Close / Perform Script ...) and then have this scripot call my "SetGlobals" script.

The SaveGlobals script could be set to run upon closing using a similar method, though you may want to only allow certain users to have this capability...

[mlemmnapa]

If you use the "squid" topology for your graph and divide it into functonal TOG's then adding a cartesion "X" join to a one record table is not a a big deal and keeps your graph clean. If you adopt the squid topology it will keep your graph from getting messy.

Mark L

[xochi]

What is the SQUID topology? (I did google it first, couldn't find an obvious link).

EDIT: found a good link Squid description

Edited November 6, 2005 by Guest

[Inky Phil]

I had a look at the squid thing out of curiosity.

As a comparative novice I found it really helpful.

I just thought I would flag it up for others

Regards

Phil

[David Garza]

Hey Guys,

Just reading over this, could you simple setup two fields for every peice of data you want to save.

--- SETTINGS table ---

gField1; Global, Calculation [ Field1 ]

Field1; Index

So when ever you set Field1, the gField1 will automatically take in that data. And since Field1 will always have the same data because it is a regular field, then you will always have a valid global.

Does that make sense or maybe I'm not sure myself?

Thanks and God Bless!

Davud Garza