Global Fields Not holding Data

[Mac3danim8]

For Global fields, Do I have to make sure nobody is in a db to update the globals?

I have a global field that is set by me each morning. Sometimes, quitting and opening again, the field didn't take.

Does a global field require that nobody be in the db??

[LiveOak]

It depends. If you are using a client copy of FM, the globals save the last values entered when only the host has the file open. If you are using server, the last values entered when the files are not on server and opened with a client copy of FM.

What you really need is to create a separate file with a single reocord and use normal text or number fields in this file to store the settings, instead of using global fields.

-bd

[LeCates]

In a multi-user system, globals are stored and managed independently for each user session, and updates are not stored with the hosted data file(s). G

However, globals do "start" with an initialized value, based on the last data stored in them when they were accessed solely by a host. There are two ways to be the sole host.

1. Open the files locally with FMP while no guests are logged on to you.

2. Open the files hosted by FMServer with FMP5.0v3 or newer as the only guest. Then open Define Fields (this promotes you temporarily as if you were sole host). Close Define Fields, modify the globals, and quit your session.

Good luck!

[kenseye]

What would be the best way to avoid these situations with globals? Should I move the globals to a separate file of "constants" and do a look-up for the field that would have been the global?

[LiveOak]

The standard approach is to create a "Preferences" file with one record and non-global text and number fields. If you use global fields in this new file, you will have the same problem.

-bd

[LiveOak]

Why use lookups at all? Just create "Constant" fields in all your files with the definition:

Constant (calculation, number, indexed) = 1

Relate all you files to the Preferences file using this relationship. You can access your settings field in the preferences file using related fields Relationship::Field.

-bd

[ November 10, 2001: Message edited by: LiveOak ]

[kenseye]

I set up my Preference file with the constants loaded in the single record with the link field. Is it ok if I convert my old global fields to text or nuber fields with look-up to the preference file data. That way I won't have to redo all my scripts to the new file?

Thanks sooooo much for your help... FM Forums has been an invaluable resource for me.

[kenseye]

I have never used the Constant function yet so creating the script is a big ? to me. I did a work around using the lookup. didn't know any other way. I 'll try to read up on the constant function but may need to return for some assistance.

Learn something new everyday....

Love this place!

[kenseye]

Sorry, I'm in the dark on this one...

Example:

Constants located in Preference file:

TaxRate = .04167

Printer = Inkjet

VSPSV = 35.95

when in the Lineitems file calculating the tax on an item, how do I pull the TaxRate value from the Preference file without doing a look up?

Sorry for being so dense...

[LiveOak]

There is not "Constant" function and no script. Let's name the fields something else to eliminate the confusion. In both the Preferences file and LineItems file using the "Define Fields" dialog, create the calculation field:

One (calculation, number, indexed) = 1

In the LineItems file, create the relationhip: "LineItemsFile by One" with the field "One" in the LineItems file matching the field "One" in the Preferences file.

When you want to access sales tax percentage, say in a script, use the reference:

LineITemsFile by One::TaxRate

This relationship is a little degenerate, since EVERY record in LineItems matches EVERY records in Preferences, but since there is ONLY one record in Preferences, this is OK. The relationship gives you access to the values stored in your Preferences file. To access these values from other files, just create a "One" field in each file and a similar relationship to the Preferences file.

-bd

[kenseye]

Just to restate so that I think I understand what you are saying:

One (calculation, number, indexed) = 1

is used to establish the relationship linking files to Preferences.

LineITemsFile by One::TaxRate

is used within a script to make the value of TaxRate available within the linked file.

Now I understand what you mean...

The only reason I used a look-up instead of the actual value from the Preferences file was that I was too lazy to change all my fee calculation scripts that included the TaxRate constant. I left my scripts the same and converted the definition of TaxRate within the LineItems file to lookup the value in Preferences.

Is that bad or should I correct all references to TaxRate in my 30+ scripts referencing TaxRate?

[kenseye]

I now understand your notation used: Constant (calculation, number, indexed) = 1 in defining the field. Thanks for your patience.

[LiveOak]

Actually, a lookup is probably more appropriate in this case. You don't want all your old invoices to be updated when you change the tax rate.

-bd