Updating Global Fields

[weseverett]

I have just converted my peer to peer platform to one with Server 8 controlling the workgroup. I am now unable to get my Global fields to update. Every time I close down, they revert to the prior setting.

Please advise.

Edited March 25, 2006 by Guest

[Ender]

This is the way globals behave in a hosted solution.

Try one of these techniques to reset/initialize the globals:

1. Have a startup script, or each individual script, initialize the globals as needed.

2. For those values that might change, and the new value must be remembered, use a file/table with one record that holds those values. Try to design such a solution so that the chance of record locking or damage caused by record locking is minimized.

3. Update the default global values when the file is not hosted.

[weseverett]

Thanks for the input. I went in and pulled it up as a non-server DB.

I am no expert, but that pretty much sucks as far as the possible solutions.

[Ender]

Think carefully about the alternative. If client machines all had access to edit shared globals, the globals would no longer be session specific. One user's actions would interfere with another's.

[weseverett]

Again, I am not a professional programmer and am learning more as I continue to program in FMPRO.

What if I converted the Global Fields in question to relational database linked fields (that are essentially fixed).

For example two fields 1) Fixed field that links the two databases set as a number, and 2) a field in the related DB that is essentially the Global Field. As I have many scripts using the Global Field, I would change it to a calculation field that would be equal to the relational field.

As issues arose, I could simply change the relational field.

This would make it fixed across all my databases, yet it would be "updateable" without having to bring the database up as a non-server version.

Would this work? There is really no fear of others changing the fields.

Edited March 26, 2006 by Guest

[Ender]

That may work, but since you haven't explained how the fields in question are used, it's hard to say if this is the best solution.

[weseverett]

OK, on a couple of the fields I have created a parallel related field and made the original field into a calculation field that = the new parallel related field. This seems to work.

Unfortunately, my DB has many many many global fields many of which are included in scripts. Accordingly, I cannot just recreate the fields as related fields and substitute them into the DB or the scripts would all have to be reworked.

I am not at all pleased with the prospect of setting up parallel relational fields, but don't see any other good way around this - other than periodically opening the DB without server and updating things.

My DB is a beast. It has >4,000 fields and is used to manage a law practice that concentrates in representing people who have received traffic tickets. I send out ~10,000 letters a month to individuals who I manage inside the DB.

I have designed the entire system myself and am self taught with no formal training - so it is not artfully designed and I have learned things through the years. In fact, I only started to use relational databases about a year ago - so much of it has been designed as a flat DB. However, reprogramming the entire system is completely out of the question, so I must rework the current beast.

[Ender]

Your structure sounds pretty unusual to require so many global fields (and so many total fields.) I know you don't want to hear it, but you should consider redesigning it. And perhaps some formal training would be useful.

You still haven't said much about your globals, and it's not clear why you'd need them all to preserve their settings. Globals are mostly used for temporary storage, like passing values between files, records, or modes, or as filters in relationships. In these cases, the globals need not be remembered from session to session; but they should be initialized by the scripts that use them.

Globals might also be used for holding a default that doesn't change much, like the current School Year or Fiscal Year, the Name and Address of the company the database is for, or graphic elements that are used in calculated interface graphics. In this case, the globals only need to be set once (or once a year.)

Rarely is it important to have a global value remembered from session to session. If there is something that must be remembered, it is usually considered "data", and given a proper home somewhere in the solution (either as a field in an existing file, or a new related file.) If you have several things that must be remembered for each user, then use a User file, that holds fields for each User's preferences (this means the design incorporates a custom login or other mechanism so that the right user's settings come up when a user opens the solution.)

[Søren Dyhr]

Your structure sounds pretty unusual to require so many global fields

Correction - Hardly any structure, is hackneyed! And you know it, you're just polite Mike.

I'll bet you have had a lot of such wrecked solutions in you inbox in need of your helping hand - looking excactly like this scattered with both globals as well as repeating fields.

--sd

[xochi]

It would be really cool if the "Set Field" script step had an option to set a global for ALL users permanently (as if you had opened the file in single user mode and set the global). I find scripts that set globals upon opening & closing to be kludgey, and the 1-record tables using the X operator are also clumsy to set up if they are used in many places...

[Søren Dyhr]

operator are also clumsy to set up if they are used in many places...

Ah! an argument for the use of the "Anchor Bouy" design model...

http://www.kevinfrank.com/anchor-buoy.html

--sd