I want to store a last modified date in a global field on a solution
that resides on FileMaker Server 5.5. The trick here is that global
fields want to reset their values to the default, when a user logs off
of the server. This means that for the next user that logs in, they
will see the default value (value set when the file was uploaded to
the server) and not the last value entered in by the previous user.

Why does this matter? What am I trying to do?

I want to store the last modified date into a global field so that I
can compare the date today with the last modified date. If there is a
difference, I'm going to run a script.

Sorry to be long winded here... A possible solution to this is to
create a preferences file that is separate and use a non-global field.
Bluh... Any ideas? Would a calculation be better?


------------------------  
Wes  
http://www.LostPants.com  
"we build applications to help  
you keep your shorts!"  

Wes wrote:

> I want to store a last modified date in a global field on a solution
> that resides on FileMaker Server 5.5. The trick here is that global
> fields want to reset their values to the default, when a user logs off
> of the server. This means that for the next user that logs in, they
> will see the default value (value set when the file was uploaded to
> the server) and not the last value entered in by the previous user.
> 
> Why does this matter? What am I trying to do?
> 
> I want to store the last modified date into a global field so that I
> can compare the date today with the last modified date. If there is a
> difference, I'm going to run a script.

> Sorry to be long winded here... A possible solution to this is to
> create a preferences file that is separate and use a non-global field.
> Bluh... Any ideas? Would a calculation be better?

Generally a preferences file is the right way to go.

However, in a multiuser file, what happens if sixty users open the 
database at the same time? Do you want that script to run sixty times?

On Fri, 09 Jul 2004 05:45:30 GMT, 42 <42@nospam.com> wrote:

>Wes wrote:
>
>> Sorry to be long winded here... A possible solution to this is to
>> create a preferences file that is separate and use a non-global field.
>> Bluh... Any ideas? Would a calculation be better?
>
>Generally a preferences file is the right way to go.
>
>However, in a multiuser file, what happens if sixty users open the 
>database at the same time? Do you want that script to run sixty times?

Because I am comparing the last mod date with today's date, the full
script only runs when the two are not equal. Each user will in fact
run the quick check every time they launch the database. But, the full
script will only run once a day. So, it shouldn't matter how many
people access the database. This is why I want to use a global field
that retains the last value instead of a date field, which can reside
on one or all records in the database.

Thanks for your help on this.


------------------------  
Wes  
http://www.LostPants.com  
"we build applications to help  
you keep your shorts!"  

Wes wrote:
> On Fri, 09 Jul 2004 05:45:30 GMT, 42 <42@nospam.com> wrote:
> 
> 
>>Wes wrote:
>>
>>
>>>Sorry to be long winded here... A possible solution to this is to
>>>create a preferences file that is separate and use a non-global field.
>>>Bluh... Any ideas? Would a calculation be better?
>>
>>Generally a preferences file is the right way to go.
>>
>>However, in a multiuser file, what happens if sixty users open the 
>>database at the same time? Do you want that script to run sixty times?
> 
> 
> Because I am comparing the last mod date with today's date, the full
> script only runs when the two are not equal. Each user will in fact
> run the quick check every time they launch the database. But, the full
> script will only run once a day.

You still need to take care. If the 2nd (or 60th) user opens the 
database -before- the first users script resets that 'global' the 2nd 
(or 60th) user will launch that script as well... depending on just what 
all it does, it could be disasterous, or just annoying.

> So, it shouldn't matter how many
> people access the database. This is why I want to use a global field
> that retains the last value instead of a date field, which can reside
> on one or all records in the database.

Yup, you want a preferences file.

> Thanks for your help on this.

Happy programming :)

In message <3lrHc.53071$WB5.43461@pd7tw2no>, 42 <42@nospam.com> wrote:
> Wes wrote:
> > On Fri, 09 Jul 2004 05:45:30 GMT, 42 <42@nospam.com> wrote:
> > 
> > 
> >>Wes wrote:
> >>
> >>
> >>>Sorry to be long winded here... A possible solution to this is to
> >>>create a preferences file that is separate and use a non-global field.
> >>>Bluh... Any ideas? Would a calculation be better?
> >>
> >>Generally a preferences file is the right way to go.
> >>
> >>However, in a multiuser file, what happens if sixty users open the 
> >>database at the same time? Do you want that script to run sixty times?
> > 
> > 
> > Because I am comparing the last mod date with today's date, the full
> > script only runs when the two are not equal. Each user will in fact
> > run the quick check every time they launch the database. But, the full
> > script will only run once a day.
> 
> You still need to take care. If the 2nd (or 60th) user opens the 
> database -before- the first users script resets that 'global' the 2nd 
> (or 60th) user will launch that script as well... depending on just what 
> all it does, it could be disasterous, or just annoying.

I'm not being clear, and here is my problem. The startup script, which runs
for everyone, checks a global field and compares it to todays date. If the
global date is older than today, an archive script is executed, and the global
field is set to todays date. If the global matches todays date, the script
simply ends.

If it worked, multiple users accessing at the same time would not be a problem
because I only care about running the script once per day. Thus, the first
time the dates do not match is the only time the script will run.

Globals aren't stored on the server. Only on the local machine.
Bluh.. have to do a preferences file.

> 
> > So, it shouldn't matter how many
> > people access the database. This is why I want to use a global field
> > that retains the last value instead of a date field, which can reside
> > on one or all records in the database.
> 
> Yup, you want a preferences file.
> 
> > Thanks for your help on this.
> 
> Happy programming :)

Wes wrote:

> In message <3lrHc.53071$WB5.43461@pd7tw2no>, 42 <42@nospam.com> wrote:
> 
>>Wes wrote:
>>
>>>On Fri, 09 Jul 2004 05:45:30 GMT, 42 <42@nospam.com> wrote:
>>>
>>>
>>>
>>>>Wes wrote:
>>>>
>>>>
>>>>
>>>>>Sorry to be long winded here... A possible solution to this is to
>>>>>create a preferences file that is separate and use a non-global field.
>>>>>Bluh... Any ideas? Would a calculation be better?
>>>>
>>>>Generally a preferences file is the right way to go.
>>>>
>>>>However, in a multiuser file, what happens if sixty users open the 
>>>>database at the same time? Do you want that script to run sixty times?
>>>
>>>
>>>Because I am comparing the last mod date with today's date, the full
>>>script only runs when the two are not equal. Each user will in fact
>>>run the quick check every time they launch the database. But, the full
>>>script will only run once a day.
>>
>>You still need to take care. If the 2nd (or 60th) user opens the 
>>database -before- the first users script resets that 'global' the 2nd 
>>(or 60th) user will launch that script as well... depending on just what 
>>all it does, it could be disasterous, or just annoying.
> 
> 
> I'm not being clear, and here is my problem. The startup script, which runs
> for everyone, checks a global field and compares it to todays date. If the
> global date is older than today, an archive script is executed, and the global
> field is set to todays date. If the global matches todays date, the script
> simply ends.
> 
> If it worked, multiple users accessing at the same time would not be a problem
> because I only care about running the script once per day. Thus, the first
> time the dates do not match is the only time the script will run.



No, I'm afraid its me that's not being clear.

If multiple users open the database at the -same- time it is possible 
for multiple users to all see the value *before* -any- of them change 
it, and thus the script will be run on -each- computer in question.

The window-of-opportunity for such a collision depends on just how long 
that startup script takes to run, and how long it takes before it 
changes the value. If the very first thing the script does is change the 
value the window is very small, if the script takes a long time, and the 
last thing it does is change the value the window is very large.

See the following time chart:

8:30:00am Computer A opens the File, and launches the startup script
8:30:01am Computer B opens the File, and launches the startup script
8:30:02am Computer A compares variable to current date, and decides it 
needs to run 'daily script'.
8:30:04am Computer B compares variable to current date, and decides it 
needs to run 'daily script'. (because computer A hasn't changed it yet!!)

8:32:00am Computer A completes 'daily script' and changes the variable 
to 'today'.
8:32:02am Computer B completes 'daily script' and changes the variable 
to 'today'.

As you can see in multi-user situation, multiple computers can run the 
same script at the same time (unless you take special precautions to 
prevent it).

> 
> Globals aren't stored on the server. Only on the local machine.

Think of globals as 'session' variables on FM server. Personally I think 
its a mistake that FM persists them in single user operation... it only 
ever leads to confusion.

> Bluh.. have to do a preferences file.

Correct.

In article <31sHc.52923$P7.25468@pd7tw3no>, 42 <42@nospam.com> wrote:

>Wes wrote:
>
>> Globals aren't stored on the server. Only on the local machine.
>
>Think of globals as 'session' variables on FM server. Personally I think 
>its a mistake that FM persists them in single user operation... it only 
>ever leads to confusion.

When I moved my (dozen-user) solution to FM server, fully grasping thisd
was my single biggest headache.  I know use globals exclusively as
variables.  Nothing remains store in them.

>> Bluh.. have to do a preferences file.
>
>Correct.

Yes.  But it's painless. :)  When I shifted to a pref file, it took me all
of about four minutes to create one and set it in motion.

Incidentally, I discovered some odd behavior with it.  My prefs is a
one-record db containing a field with the numeral one in it.  Over in the
main db, I have ma constant field that is a calculation field where the
calc is a numeral one.  I relate the main db to the prefs file via this
constant relationship.  My assumption was that the text, number & date
fields in my prefs file would act as de facto globals, as there were never
any "choices" for FM to make.

But it turns out that there is a need to create globals in the prefs file,
so that scripts can set them to the contents of the "real" fields & pass
the info back to the main db.  I need to do this with scrupts only, for
some reason.

Steve Brown

In message <31sHc.52923$P7.25468@pd7tw3no>, 42 <42@nospam.com> wrote:
> No, I'm afraid its me that's not being clear.
> 
> If multiple users open the database at the -same- time it is possible 
> for multiple users to all see the value *before* -any- of them change 
> it, and thus the script will be run on -each- computer in question.
> 
> The window-of-opportunity for such a collision depends on just how long 
> that startup script takes to run, and how long it takes before it 
> changes the value. If the very first thing the script does is change the 
> value the window is very small, if the script takes a long time, and the 
> last thing it does is change the value the window is very large.
> 
> See the following time chart:
> 
> 8:30:00am Computer A opens the File, and launches the startup script
> 8:30:01am Computer B opens the File, and launches the startup script
> 8:30:02am Computer A compares variable to current date, and decides it 
> needs to run 'daily script'.
> 8:30:04am Computer B compares variable to current date, and decides it 
> needs to run 'daily script'. (because computer A hasn't changed it yet!!)
> 
> 8:32:00am Computer A completes 'daily script' and changes the variable 
> to 'today'.
> 8:32:02am Computer B completes 'daily script' and changes the variable 
> to 'today'.
> 
> As you can see in multi-user situation, multiple computers can run the 
> same script at the same time (unless you take special precautions to 
> prevent it).
> 
> > 
> > Globals aren't stored on the server. Only on the local machine.
> 
> Think of globals as 'session' variables on FM server. Personally I think 
> its a mistake that FM persists them in single user operation... it only 
> ever leads to confusion.
> 
> > Bluh.. have to do a preferences file.
> 
> Correct.

Thanks 42. I understood the collision thing, but it win't be a big deal to
me since the archive script could run simultaneously with no harm except speed.
I'm essentially flipping a bit at first startup if the dates don't match,
and running a script only then.

Wouldn't it be cool if you could specify how networked globals should function
at development time? Maybe even for each global you create, this could be
defined. No more pref files!

-------------------------------------  
Wes  
http://www.LostPants.com  
"we build applications to help  
you keep your shorts!"  

In message <eyebrown-0907040822470001@sdn-ap-034tnnashp0244.dialsprint.net>,
eyebrown@mindspring.com wrote:
> In article <31sHc.52923$P7.25468@pd7tw3no>, 42 <42@nospam.com> wrote:
> 
> >Wes wrote:
> >
> >> Globals aren't stored on the server. Only on the local machine.
> >
> >Think of globals as 'session' variables on FM server. Personally I think 
> >its a mistake that FM persists them in single user operation... it only 
> >ever leads to confusion.
> 
> When I moved my (dozen-user) solution to FM server, fully grasping thisd
> was my single biggest headache.  I know use globals exclusively as
> variables.  Nothing remains store in them.
> 
> >> Bluh.. have to do a preferences file.
> >
> >Correct.
> 
> Yes.  But it's painless. :)  When I shifted to a pref file, it took me all
> of about four minutes to create one and set it in motion.
> 
> Incidentally, I discovered some odd behavior with it.  My prefs is a
> one-record db containing a field with the numeral one in it.  Over in the
> main db, I have ma constant field that is a calculation field where the
> calc is a numeral one.  I relate the main db to the prefs file via this
> constant relationship.  My assumption was that the text, number & date
> fields in my prefs file would act as de facto globals, as there were never
> any "choices" for FM to make.
> 
> But it turns out that there is a need to create globals in the prefs file,
> so that scripts can set them to the contents of the "real" fields & pass
> the info back to the main db.  I need to do this with scrupts only, for
> some reason.
> 
> Steve Brown

I'm hoping I can get away with just having to create 1 file that stores prefs
for each solution I have running on the server. Each record will act as the
prefs for a specific solution. I'll prbably create a relationship between
main & this prefs file, and ensure I am reading/writing data om the correct
record for the solution being run over the network.

The problem of globals not retaining values set over the network would still
remain here in your solution Steve. Unless the globals get ignored when the
user shuts down the solution. For me, I need to store this info for the next
user who comes along.

-------------------------------------  
Wes  
http://www.LostPants.com  
"we build applications to help  
you keep your shorts!"  

In article <wNxHc.47881$a24.8182@attbi_s03>, "Wes"
<wchester@lostXXXpants.com> wrote:

>I'm hoping I can get away with just having to create 1 file that stores prefs
>for each solution I have running on the server.

I do this.  I have one prefs file (with only one record) that holds prefs
for about eight different solutions on my server.  I made a different
layout for each, where the fields for that solution can be found.  In
field definition, the fields for all eight are in one big list, of course,
but careful field naming made this painless.  The only reason I made eight
layouts (no one sees these but me) is to make it less confusing during
development.

>Each record will act as the
>prefs for a specific solution.

I think it unnecessarily clumsy to make a different record for each
solution.  Then you'd have to find that record via a script whenever the
prefs need to be altered or consulted (or set up a bunch of relationships
in the main database so the correct Go To Related Record function will
work).  Also, you can now no longer relate to the prefs ile via a constant
relationship.  One record only, with a set of fields for each solution is
much easier to deal with, particularly when passing data back and forth.

>The problem of globals not retaining values set over the network would still
>remain here in your solution Steve. Unless the globals get ignored when the
>user shuts down the solution. For me, I need to store this info for the next
>user who comes along.

The info is never stored in the globals, but in actual text, number or
date fields in the single record.  You can display the data on layouts,
via the constant relationship (which one poster once called a "degenerate
relationship").  You can reference these fields in calculations.  In some
scripts, however, to get the info you need to run a little external script
in the prefs file that will set a global temporarily with the real field
data, then pass it over and set fields in the main database(s) this way. 
The user never even sees any globals, or is even aware of them.

The globals never store data.  They only hold it briefly, when needed. 
Essentially, in a served environment, globals act as variables in
functions, not as storage.  At least in my slowly growing understanding,
which is fairly limited.  But I can attest that it works cleanly and
hasslefree for me.

Steve Brown

In message <eyebrown-0907041850200001@sdn-ap-030tnnashp0095.dialsprint.net>,
eyebrown@mindspring.com wrote:
> In article <wNxHc.47881$a24.8182@attbi_s03>, "Wes"
> <wchester@lostXXXpants.com> wrote:
> 
> >I'm hoping I can get away with just having to create 1 file that stores
prefs
> >for each solution I have running on the server.
> 
> I do this.  I have one prefs file (with only one record) that holds prefs
> for about eight different solutions on my server.  I made a different
> layout for each, where the fields for that solution can be found.  In
> field definition, the fields for all eight are in one big list, of course,
> but careful field naming made this painless.  The only reason I made eight
> layouts (no one sees these but me) is to make it less confusing during
> development.
> 
> >Each record will act as the
> >prefs for a specific solution.
> 
> I think it unnecessarily clumsy to make a different record for each
> solution.  Then you'd have to find that record via a script whenever the
> prefs need to be altered or consulted (or set up a bunch of relationships
> in the main database so the correct Go To Related Record function will
> work).  Also, you can now no longer relate to the prefs ile via a constant
> relationship.  One record only, with a set of fields for each solution is
> much easier to deal with, particularly when passing data back and forth.
> 
> >The problem of globals not retaining values set over the network would
still
> >remain here in your solution Steve. Unless the globals get ignored when
the
> >user shuts down the solution. For me, I need to store this info for the
next
> >user who comes along.
> 
> The info is never stored in the globals, but in actual text, number or
> date fields in the single record.  You can display the data on layouts,
> via the constant relationship (which one poster once called a "degenerate
> relationship").  You can reference these fields in calculations.  In some
> scripts, however, to get the info you need to run a little external script
> in the prefs file that will set a global temporarily with the real field
> data, then pass it over and set fields in the main database(s) this way. 
> The user never even sees any globals, or is even aware of them.
> 
> The globals never store data.  They only hold it briefly, when needed. 
> Essentially, in a served environment, globals act as variables in
> functions, not as storage.  At least in my slowly growing understanding,
> which is fairly limited.  But I can attest that it works cleanly and
> hasslefree for me.
> 
> Steve Brown

Good info. Thanks for your feedback. I may use only one record for all
solutions prefs as you suggested. We'll see how this works out. Anyway, thanks.

-------------------------------------  
Wes  
http://www.LostPants.com  
"we build applications to help  
you keep your shorts!"