Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mysterious global value appears

Status
Not open for further replies.

CryoGen

MIS
Apr 15, 2004
86
0
0
US
OK, here's an interesting one. I have a solutiuon that was created by a third-party developer. It contains a global field whose value serves as the key to a relationship for various different report formats. What it does is really irrelevant here.

Here's what's curious: at startup it has a value that is being set to "Cost Center". We have a value list that provides the different values that drive that relationship and we have since removed "Cost Center" from that list. But whenever the database is started, that value is still added to the global field.

We checked and there is no set field command on a startup script that populates that value. In fact, we cleared the field, turned on the data viewer and the debugger, and then shut down the database. When we start it up the "Cost Center" value appears in the data viewer before any script runs. A quick check of the field definitions shows that there is no auto enter values set, so we are a little flumoxed about where and when that value is being set.

Anybody ever seen anything like this? We're going to call the developer to find out why, but we'd like to figure this out. Any ideas?
 
CryoGen,

Global fields retain whatever value was in them the last time the file was closed while in the single user mode.

There is a document called "White Paper for Novices" on this website:


It explains how global fields work and has LOTS of other good information for people that are new to Filemaker and even some good for ideas for more experienced folks as well.

-Striker
 
OK, except that we cleared the field before closing the database. Once we deleted the value in the global field, closed and restarted the database, the "Cost Center" value reappeared. As I said, we had the debugger AND the data viewer on, and the value was set before any script had run. It does not make sense why.
 
The key phrase is "single user." You need to open the file as the sole user, set the global to whatever you want it to be, and then close the file. That should change the value.

Are you running Filemaker Server?

-Striker
 
Yes, this is running on FMP Server 8. It is multi-user. And I think I understand what you're saying. But if this is a multi-user file, and every multi-user file creates a new blank global for each user, why is ours being set to "Cost Center". Is it because that was the original value in the global when it was created single-user?

I mean, we can bypass this nonsense with a simple set field script on startup, but I'd like to know why it's happening. Thanks for your help -- past and future.
 
You understand correctly. I agree that it is odd behaviour but it has been working that way for many years now and some developers rely on it. I try not to rely on that behaviour myself because it is pretty easy to accidentially change the value in a global field when you are designing the database.

Another way to populate a global field with a "constant" is to make the global field a calculation. For instance if I wanted to build a relationship upon "active" orders I could create a field and call it whatever and have the calculated value be simply "Active". I like this method because it will be populated with the correct value no matter what happens. Startup scripts that run automatically on file opening can be bypassed if the file is opened via a relationship. For instance, lets say you have a purchase order that has a portal that shows the line items from the related line item table. Upon opening the main PO layout the line items file will open automatically so it can list the lines that appear on the PO yet any startup script in the line item file will not run.

This point may be moot if all of your tables are in one file but back in the version 6 and earlier days there was only 1 table per file allowed so this was sometimes a problem.

That "white paper" may address this situation as well. I have read the whole thing and agree with most of it but can't remember if that particular section is in there.

-Striker
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top