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@g44g2000cwa.googlegroups.com>,
aditsu@gmail.com wrote:

>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?

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@gmail.com wrote:
> 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
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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@g43g2000cwa.googlegroups.com>, 
aditsu@gmail.com says...
> 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.

You most certainly do!! That's what the regular fields are! It wouldn't 
be much of a database without them.

> 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

#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.
 
> 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.

Consider it confirmed.

-regards,
Dave

42 wrote:
> > I don't really need global
> > fields that affect all users/sessions and are stored.
>
> You most certainly do!! That's what the regular fields are! It wouldn't
> be much of a database without them.

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

> > Sometimes I want to change the initial value [...]
>
> #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.

Agreed

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

That's not a problem in my case.

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

But then it would not be local to each session.

Thanks
Adrian

In article <1130228530.705018.30990@g47g2000cwa.googlegroups.com>, 
aditsu@gmail.com says...
> 
> 42 wrote:
> > > I don't really need global
> > > fields that affect all users/sessions and are stored.
> >
> > You most certainly do!! That's what the regular fields are! It wouldn't
> > be much of a database without them.
> 
> Well, I was talking about global fields (one field per table, not per
> record), to be used as variables or temporary input fields.

Naturally. I was just poking fun.

> > > Sometimes I want to change the initial value [...]
> >
> > #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.
> 
> Agreed
> 
> > #2 has issues in that you must restart the database on each client to
> > make any changes.
> 
> That's not a problem in my case.
> 
> > #3 Using a single record "preferences" table is generally the best
> > solution.
> 
> But then it would not be local to each session.

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