I have a question about the behavior of global fields and FM8 variables
in a shared database.
By the way, I am using FMS7 for hosting some databases, and the clients
are FM7 and FM8 (will change all to FM8).

First, I noticed the following behavior for global fields:
- if I have a local (not shared) database, then if I change a global
field and close FM, the value is saved
- if I take the database and host it on the server, each client will
see the last saved value before hosting, and all changes to global
fields are visible only in the current session, which means:
-- if one client modifies a global field, other clients will not see
the changed value; it's as if each session has a separate copy of that
field
-- the modified values are not saved to the server - it keeps the last
value that was saved before hosting

Can you please confirm this behavior (I'm not sure I got it right) and
perhaps explain it if you know the reasoning?

The second question is: do global variables ($$xxx) in FM8 have the
same behavior as described above?

Thanks
Adrian

In article <1130141447.962212.107140 (AT) g44g2000cwa (DOT) googlegroups.com>,
aditsu (AT) gmail (DOT) com wrote:

In general, this is how global fields behave in a served environment. I'm
using FM6, but I don't think it's much different in 7. You have to think
of globals as temporary variable fields, definitely not a place to store
either permanent information, or data intended to be used by multiple
users. A scandalized old Unix guy at work loves to shout "Globals are
local!" He finds this endlessly funny. It just indicates that the
feature is not well-named.

A general way to deal with this I use is to set up a one-record served
database, call it storage.fp7 or something. Make a number field called
"Constant" and put a one in it. Make number calc fields in all other dbs
that need to access this, and the calc is a one. The field should always
contain a one across all records. Set up your relationships using these
Constant fields as keys.

In Storage, make a bunch of text fields, number fields, container fields,
etc. that you need to store info to be commonly used by all users. *Not*
global fields, regular fields. This information can be seen and used
across the constant relationship. Experiment. In some cases you might
need to make some globals in Storage and set up some scripts to
temporarily fill them when data is being passed across.

But the key point is that your info ius now safely stored in "real" fields
instead of globals, yet it is accessible by multiple users simultaneously,
as if it were storerd in globals.

Steve Brown

You have it right for global fields. Global variables are only kept
alive per person per session. They are never stored with the database
regardless of whether it is opened local or shared.

aditsu (AT) gmail (DOT) com wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

Thank you both for your replies.
I think I can live with this functionality, I don't really need global
fields that affect all users/sessions and are stored. Sometimes I want
to change the initial value of some global fields, and I think I know
two ways to do that:
1. close the database, open it locally and change the desired values
(cleaner but more complicated)
2. use the startup script in file options

I also wanted to confirm that global variables are local to each
session. This is good for what I need to do. Of course, I didn't expect
them to be stored in the database.

Thanks
Adrian

In article <1130218446.700672.316050 (AT) g43g2000cwa (DOT) googlegroups.com>,
aditsu (AT) gmail (DOT) com says...
You most certainly do!! That's what the regular fields are! It wouldn't
be much of a database without them.

#1 has issues in that you must restart the database on the server to
make any changes. Its also vulnerable to inadvertantly getting reset
during an import/upgrade.

#2 has issues in that you must restart the database on each client to
make any changes.

#3 Using a single record "preferences" table is generally the best
solution.

Consider it confirmed.

-regards,
Dave

42 wrote:
Well, I was talking about global fields (one field per table, not per
record), to be used as variables or temporary input fields.

Agreed

That's not a problem in my case.

But then it would not be local to each session.

Thanks
Adrian

In article <1130228530.705018.30990 (AT) g47g2000cwa (DOT) googlegroups.com>,
aditsu (AT) gmail (DOT) com says...
Naturally. I was just poking fun.

Of course. I wasn't under the impression that was actually a requirement
for what you were trying to do.

It sounded more like you wanted to have some "system constants"... e.g.
a "tax rate", implemented as a global, and wanted to know how and when
changing it would be reflected, on the odd ocassion that you wanted to
change the value.

For system constants a single record table works best while globals are
more suited for session variables

With respect to system constants, globals can be used, as you've noted,
provided you deal with initializing them, and are willing to put up with
restarts to change them, where single record tables have neither
drawback.

As an aside, if you do need 'per user' variables that do get persisted
-- a common enough requirement (for storing user "preferences"), a table
with a record for each user is the way to go.

-regards,
Dave