[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

FM - Global Gone Crazy  :)

Posted on 2011-10-10
7
Medium Priority
?
641 Views
Last Modified: 2012-05-12
I have a global field, VACANCY::VacChangeMailInfo_G, that seems to have a life of its own.  In the process of changing a script from running on open to scheduled, I must have missed something, because this field continues to fill in with data on open of the db.  Even if I delete this info, it reappears.  I've looked at the script; I've checked all File and Layout script triggers, and finally checked the DDR for all instances of VACANCY::VacChangeMailInfo_G where it might be set in the set field script step and cannot find it.  The strange aspect is that one of the two vacancies it lists is not even a vacancy any longer, so where is this data being saved or drawn from?

The only thing I can think of is an auto enter in some field that fills in this global in question, but cannot find that either.  Thanks for any suggestions or brainstorms.

P.S. - I have done a workaround in that I set this global to "" at the beginning of the scheduled script; however, globals are supposed to zero out on close and I've even deleted the info before closing out.
0
Comment
Question by:rvfowler2
7 Comments
 
LVL 6

Accepted Solution

by:
ThomDroz earned 500 total points
ID: 36946001
Globals (on a hosted file) always return to the value they had when the file was last open and NOT hosted.

You can unhost it, then open it directly, set the value, then close and rehost........
0
 
LVL 1

Assisted Solution

by:soholm
soholm earned 1000 total points
ID: 36948753
ThomDroz is absolutely right. This FM-behaviour of remembering the global fields like this can be annoying. A common solution is to run a startup script when opening the file. This script sets the values of any global fields that you want to clear.
You may want to store the init values in a custom function to keep them in a separate place (like a preference pane), and call them from the custom function, e.g.: fnSetupValues("email"). This will also allow for a mix of  constant values and dynamic values, some of which can be calculated 'behind the scenes' in the custom function based on dynamic data depending on the current user.
But I guess this can also just be done in the startup script without a custom function.
0
 
LVL 25

Assisted Solution

by:Will Loving
Will Loving earned 500 total points
ID: 36949607
In addition to ThomDroz's note, I think the other important point is:

In the process of changing a script from running on open to scheduled
I'm not actually sure what happens when you set a global field from a scheduled script rather than a regular script, which as ThomDroz notes changes the field value locally but that is only retained for the duration of the files being open on the client.

An alternative that you might want to consider, and which has some advantages over globals, is to create a Preferences table with a single record in it. YOu then create a set of relationships between this table and any other table that need to reference using a Cartesian "X" join, meaning all records are related to all other records. The advantage to this is that the fields are NOT globals and that if one user changes them they change for all users and are retained on the server. Of course, you may also have some globals in that table because you want the behavior Thom described but it does give you an alternative way of storing preferences.

For this one table, you may also wish to turn off the ability to Add or Delete records for a users except Admin in the security settings.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
LVL 1

Expert Comment

by:soholm
ID: 36949858
Having reread your post it sounds a bit like you are using a global field to store data, that should really be stored in i global field. A global field is really only suited for session wide data. willmcn's method is a good solid way of saving preference like settings. If the data is of static nature, and thus should always be the same, you could save a table and put the data in a custom function as mentioned above, or you could set some $$globalVariables in a startup script. (Mind you, the $$globalVariables will not be safe if data is confidential.)
One single drawback to the sensible preference table model is that you need a relationship in each TOG (Table Occurence Group) to access the setting fields. Unless you use globals ... and then we're back where we started. ;-)
0
 
LVL 1

Assisted Solution

by:soholm
soholm earned 1000 total points
ID: 36949894
Sorry, I meant to write:

»Having re-read your post it sounds a bit like you are using a global field to store data, that really should NOT be stored in i global field.«

My main point is, your choice of method really depends on the type data you are dealing with. Is it personal, public, session dependent or ...?!
0
 
LVL 2

Author Closing Comment

by:rvfowler2
ID: 36950625
Excellent suggestions.  I had forgotten that "Globals (on a hosted file) always return to the value they had when the file was last open and NOT hosted."  I guess this is what happens when I moved from a client run script to a server scheduled script.  

I am using this global to gather data on changes made to a table since the previous day (adds or deletions to Vacancies; Thom would appreciate the Real Estate reference).  

However, I do already have a table I call PermGlobals that only has one record and that I have related to every other table, which I can use.  I have used this to enter static info on the name of the Exchange server, dbadmin email, etc., for SMTP settings after having to change over 300 email scripts when we upgraded to a new server last month.  I succeeded in removing all static info in the SMTP email script steps.
0
 
LVL 2

Author Comment

by:rvfowler2
ID: 36950633
I said "static," but probably a better phrase is getting rid of all "hard coded" info in the SMTP settings.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Problem: You have a hosted FileMaker database and users are tired of having to use Open Remote or Open Recent to access the database. They say, "can't you just give us something to double-click on rather than have to go through those dialogs?" An…
Having just upgraded from Filemaker 11 to Filemaker 12 over the weekend, we thought we would add some tips for others making the same move.  In general, our installation went without incident. Please note that this is not a replacement for Chapter 5…
Integration Management Part 2
As many of you are aware about Scanpst.exe utility which is owned by Microsoft itself to repair inaccessible or damaged PST files, but the question is do you really think Scanpst.exe is capable to repair all sorts of PST related corruption issues?
Suggested Courses

825 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question