In a multi-user environment global values are cleared when the user logs out and created afresh when they log in and set the values again. So... I'm not sure where your legacy of global values is coming from. Globals do behave differently if you set them on the host file, without sharing, etc, but anyway I'm not sure what you think the problem will be in the future.
EDIT: sorry, misread 'variables' for 'fields' - though the principle is still the same. The global variables are cleared when the file is closed.
One method I used to prune a lot of 'deadwood' out of my tables in an old legacy system I was updating from 5.5 to 10 was to use FileMaker Advanced's Database Design Report (DDR).
I'd open the database and go to manage | database | fields. I'd find a field I thought might not be needed anymore and change the field name to something very unique such as adding a bunch of XXX's to the field name. I might select several suspect fields and "tag" them with different letter combinations at the same time. Then, I'd generate the DDR in the default HTML format and use my browser to text search for each of these letter combintations that I used to "tag" the fields I was investigating. You can use Find Next to quickly jump from location to location in the report where each field appears. If it does not appear in a script, calculation, relationship or layout in a way that shows it was still needed, I could then safely delete the field.
I think you misunderstood my Q. It's not that the fields are cleared dynamically at startup. It's that I want to de-cruft my scripts for maintenance purposes. I realize that these global variables are inocuous, but every once in awhile I will come across one and after a huge amount of effort I find that it is not referenced anywhere else due to code changes made later on. These are confusing at maintenence time. I want to easily identify this situation and delete the reference(s).
As per my original posting, a call graph would be nice too to help determine which scripts are not being used. I add an "_D" to scripts I use only for development so that helps. But in the course of development, unused scripts pop up like mushrooms and I want an easy way to ID these and get rid of them. You can make an argument I need more discipline, but there is no reason software can't help here.
I will try PhilModJunk's suggestion and see if this works.
Thanks for the input.
I also have developed the habit of defining all global fields not needed for a relationship definition in a single "globals" table. This, at least, puts them all in one place for a bit easier management of them.
I also find that I am using variables in many places where I would otherwise use a global field...
Now I'm even more confused, dzittin: are we talking global variables or global fields?
PhilModJunk, I am coming to the same conclusion that global fields are better. If you delete a global field, you will get a notification that it is being used by a script(s). I think I am going to stop using global variables unless someone can tell me why this is not a good idea.
Sorbsbuster writes: "dzittin: are we talking global variables or global fields?"
Ok, I will take both :-) :-)
What I am saying is that it is easy to create fields (especially globals), global variables and for that matter scripts that are "de-referenced" in the course of a large programming job. These dregs will go out in the release. As long as thorough testing occurs before rrelease, all is fine. The problem comes that if/when a bug is found the developer can spend extra time trying to figure out if something is indeed used. So cruft tends to up maintenance time and it possibly slows and bloats data base operations.
Of course a thorough code review should help, but it's not perfect. I have 41 scripts, 2 are sandbox scripts to try out ideas, the rest will go with the release and every once in awhile I find a script, a script-instanced variable, a global variable, a field, etc. that is not being used anywhere. I want to get rid of these and from programming in other areas, I know that software can find these kind of stuff.
Again, it's not just global variables or global fields - it's everything that is creating cruft (not being used).
Thanks for the input.
Yeah, I definitely don't limit such "spring cleaning" to just global fields. I look at all of them, Globals just tend to be harder to track as they could ber referenced anywhere in the file not just from locations with a valid link to the defining table.
Actually, I prefer variables over globals for many purposes, not the least of which are simpler table definitions with shorter field lists. They can't be used in a relationship or for direct user entry so they still have a purpose. Adding documentary text to a spot in your DB where you list all global variable used could be useful, but since global variables only exist where they ar actually used, cleaning them out tends to happen naturally.
If I could make a wish, at a minium, I want a Unix grep-like command that I can use when working with my scripts. Then, if I run across a variable, and want to know where else it is referenced: grep "variablename", would uncover all instances meaning script-instance variables, global variables and ideally fields with the same name, global or otherwise.
As it stands now, it can take a ___long___ time to survey each file to see where a given global variable occurs. A "grep" would solve that quickly.
Today I can put in a substring for a script name in the script manager and get a list of all scripts with that substring. Imagine having a "grep" or find command which produces a sublist of scripts which contain that name. One can then view each script in turn. Sounds useful to me.
Thanks for the pointer.
I put in a wishlist for a script-global find and a call graph production tool that shows a script call hierarchy and any unused references in each script (if that is possible and I hope would include global fields, variables, local varibales, etc.).