We enter the info in the global fields using the host computer and committed the records but we still have to restart the host to be able to see the entered fields on the client computers. Is there a method to avoid this restart workaround?

I'm pretty sure thats what you have to do. If there is another way I would like to hear it to.

Global fields are local to each Client. So commiting a record will do nothing as the Global field technically has nothing to do with the record.

Michael

We enter the info in the global fields using the host computer and committed the records but we still have to restart the host to be able to see the entered fields on the client computers. Is there a method to avoid this restart workaround?

-- Yes, don't use globals for something you want to take effect solution wide.

If you want to make a change in this fashion then you need to have a table of actual data which your globals are then set to as part of your start up script.

If you want to make a change in this fashion then you need to have a table of actual data which your globals are then set to as part of your start up script.

Curious for what reason would you need to set them at startup if it was a seperate table with actual data? Or am I misunderstanding?

Michael

Okay:

General Advantages of globals

- They are system wide, no need for relationships... anywhere.

- In a hosted environment, the globals are attached to sessions -- i.e. each person who logs in has their own set. This lets you for example have a home screen with only one record with information drawn through portals from all over the database. Because each user has an individual session based gobal, no other use will experience the effects of a change made to that global.

- **Note that the data stored here, is only stored until the user closes down the file -- the session terminates here. When the user opens the file again, the globals are reinitialized with the last values they had before the file was put on the server.

General Disadvantages.

If you want to set default values to your globals, the only way you can really do it is to have a table. When your DB opens, the script runs through the table and initializes each of your Global fields with whatever value you specify there.

Not a great explanation but they're dodgey things global fields (dodgey, but extremely useful in the sense of multi-user environment).

for what reason would you need to set them at startup if it was a seperate table with actual data?

Because, globals exhibit special properties (above) unlike ordinary fields.

"no need for relationships... anywhere."

Dawned on me while I was afk...lol

I am using the global fields to hold quoted prices for bids. The quantities and the extended prices change every record but the prices are constant. I have the estimator trained to go to the host to enter his prices and I was hoping to avoid stopping everyone working on the bid to restart.

The global field is a hold over from before Version 7.

Thanks for the help

I don't recommend you use globals for this. It's a misuse, your prices and quantities should go into a related table.