Can't say what the 'why' is without more details but for defensive coding purposes: after the find, do a plausibility check to make sure that the current found set is within reasonable bounds or at a minimum not equal to the total record count.
You should probably also check to see if your variables contain any data or the type of data that you expect, and exit the script if they don't.
Thanks. That's a good advice . I will add some security and validity checks to the script.
Still trying to figure how what happened was possible though .
Even with an empty $user or $date , the found set should be nil so the replace field contents function should do nothing.
That is so weird.
I ran this script regularly for many months without this happening.
I noticed immediately that something was wrong because when I ran it it was way slower than it should have been with the $user and $date selected.
has it always been run as a PSoS? If not then keep in mind that the PSoS script inherits nothing from your session and also runs the OnOpen script of the file.
Yes, it was always PSOS.
The script operations are all based on the 2 parameters received. (go to layout, filter records with the 2 parameters, set to archive or delete).
I guess I will have to test it on the server again on a copy of my db . I just can't get to behave like it did on my local copy.
"Even with an empty $user or $date , the found set should be nil so the replace field contents function should do nothing."
Not necessarily. If both are null, you'll get a different error (400) and the result will be the "default found set" which is often all records. (It's the last found set before this find, on start up that's usually "all records").
I tried it on my local copy.
I passed an empty parameter.
$user and $date were both empty
perform find (table::date<$date and table::user==$user)
I do not get error 400 but error 401 and no found set.
Is that different with PSOS ?
400 means that no criteria was specified in the find. Apparently, at least one other criterion than the two variables is specified in your scripted find and thus you get 401.
By going with "==" $user when $user is null, you're actually specifying a criteria...you're doing find for when user is empty.
Found the problem.
I had changed the set variable $date in my last version of the script.
The line is actually
Set variable ($date ; GetAsDate(GetValue ( Get ( ScriptParameter ) ; 2 )))
That generates an error 508 (Invalid value entered in Find mode) when executed on the server but no error when executed locally on my test database.
The fix is easy.
Thanks to everyone who replied