Maybe something is global that should be stored and it get cleared when you close the DB. Just a hunch.
Have you debugged your script?
agnes b. riley . filemaker and web development
FileMaker Business Alliance . FileMaker Technical Network
T 201-299-6223 (NJ) .
FileMaker Certified in 10 and 11
people + products + events + todos + invoices + documents = productivity
Runs well in the debugger but I think there may be something to one of the globals having persistent data in it. I will examine that - thanks for the pointer.
"A sure cure for seasickness is to sit under a tree." --- Spike Milligan
Well. A quick reveals all the globals open up empty.
"I sometimes think that God in creating man somewhat overestimated his ability." --- Oscar Wilde
Are you sure that All Globals are being set correctly before the script progresses? Use the debugger and data viewer to step thru. It sounds like some global is not being correctly set before proceeding.
Be sure that any global which should be empty is empty, and vice-versa. The script should set every global, even if only to null (using Case tests to determing the correct values), to be sure that session values/globals are not accidentally retained during other searches in the same session.
If a global field is created on a server it will always come up empty when the database is opened. If created in a local copy it will have the last value set when the file is closed.
To resolve this I use an on open script to initialize global fields to the desired initial value.
Conditional formatting (Self = "") tells me all the global fields are empty upon db open. A utility eraser confirms that. I populate the fields, run the routine, it fails. I run again - it works.
It occurs to me that I could rewrite the whole thing and it would work.
"A mistake is simply another way of doing things." --- Katharine Graham
And don't forget that if a scheduled server script sets globals, those will be the default values next time a user opens the file. So yes, having a startup script that sets them the way you want is important.
Are you using after set globals fields and local variables commit?
It is also good practice to have a script clear global fields/variable at the end of the script if they are no longer to be used. This leaves things nice and clean for using other scripts.
There is a real danger that a developer will use a global variable with a name such as $$date or $$total in more than one script, and it's not best practice to leave an old value hanging about that something else might recognize and try to use by accident.
No $$ globals were involve in the production of this script. All $Globals reset at start of script, then reloaded (even though they shouldn't exist).
I rewrote the script - looks and prints exactly the same but works this time.
"As a rule, said Holmes, the more bizarre a thing is the less mysterious it proves to be. It is your commonplace, featureless crimes which are really puzzling, just as a commonplace face is the most difficult to identify." --- Arthur Conan Doyle