need help troubleshooting a script

[dansmith65]

I need help troubleshooting a script. I am having intermittent errors with the script this section of scripting came from. The error is NOT re-producable by me; I just ran this script on 50 different records and all worked fine. In real-world use at our company the error occures approx. 5% of the time.

The purpose of this script is to find all records released on the same day to the selected client (NameLink field). The problem is that even though a record with the selected client name and DateReleased exists - the script sometimes gives a 401 error - no records found.

-------------------------------------

SCRIPT STEPS

-------------------------------------

#OPEN NEW WINDOW

New Window [ Name: $WindowName; Height: 0; Width: 0; Top: 0; Left: 0 ]

Freeze Window

#FIND RECORDS

Set Variable [ $NameLink; Value:JOB__Jobs::NameLink__lct ]

Set Variable [ $DateReleased; Value:JOB__Jobs::DateReleased ]

Enter Find Mode [ ]

Set Variable [ $ErrorEnterFindMode; Value:Get( LastError ) ]

Set Field [ JOB__Jobs::NameLink__lct; $NameLink ]

Set Field [ JOB__Jobs::DateReleased; GetAsDate( $DateReleased ) ]

Set Variable [ $FindModeNameLink; Value:JOB__Jobs::NameLink__lct ]

Set Variable [ $FindModeDateReleased; Value:JOB__Jobs::DateReleased ]

Perform Find [ ]

Set Variable [ $ErrorPerformFind; Value:Get( LastError ) ]

-------------------------------------

VARIABLE VALUES AFTER SCRIPT HAS RUN

-------------------------------------

$NameLink: Smith, Jon

$DateReleased: 6/20/2008

$ErrorEnterFindMode: 0

$ErrorPerformFind: 401

$FindModeNameLink: Smith, Jon

$FindModeDateReleased: 6/20/2008

JOB__Print__ReleaseForm.txt

Edited July 17, 2008 by Guest
attached entire script in a text document

[T-Square]

Um, but what is the problem?

Also, for debugging purposes, the whole script is necessary.

Proceeding willy-nilly, the result that you list notes error 401 (no records found). Is the problem that there are actually records attached, and they aren't turning up? If so, is there a problem with the data on either end of the relationship? Is there something special about John Smith or the related records?

[dansmith65]

thanks for the help - sometimes it's the littlist things we overlook. Like actually saying the problem i'm running into. lol

[dansmith65]

The script is beeing run from a layout based on the JOB__Jobs table occurence.

There is nothing that I know of special about the Smith, Jon record. Actually, I just used a dummy name for this example - it has happened for mutiple clients.

[T-Square]

I'll assume that you've tried stepping through the script and watching what happens.

Frankly, if the problem is sporadic, I would think that the most likely problem is data related, and I would try to figure out whether there are any weird values in the dataset. Maybe you can run through the entire dataset and kick out potentially wrong results (e.g., error 401 entries). A scan of these records might point to some answers.

[dansmith65]

From what you are saying, I get the impression that this error is happening on certain records in the database. However, it's not record specific - it's instance specific. Everytime I have heard about this error happening my quick-fix has always been to "try it again" - it's always worked the second time (on the same record).

Yes, I have tried stepping through the script.

I had to resort to making the script create a log of when this happens so that I could even learn as much as I did about it.

Edited July 17, 2008 by Guest
forgot something

[T-Square]

Well, besides considering the phase of the moon, I'm stumped. Any chance that there's something presetting the found set (such that the next search is on the smaller subset rather than the entire table)? Are your users engaging in any weird pre-script rituals that you haven't accounted for? Perhaps an incantation or some such?

Perhaps someone else might have suggestions.

[dansmith65]

Superstitious eh?

Well, I'm becoming superstitious also. My grand plan for resolving this: delete the perform find script step, then add it again. Perhaps the old one went bad? Also added a commit record script step at the beggining of the script.

Or maybe I could relase an office memo:

"Effective immediatly:

Any employee found practicing witchcraft while on company time will be sent home on thier broom!"

Hey, I just got another idea:

since it always works the second time arround, i'll just run a loop so that it loop's till it finds records. The only downside of course is it still doesn't find records and loops untill the next full moon.

Any chance that there's something presetting the found set...

I dont see any way that could happen.

[Vaughan]

First thing, where is the Set Error Capture [ on ] step located? I can see you're trapping errors into variables, but cannot see this step.

If it's right at the beginning of the script, I'd suggest not doing it this way. Instead, always run scripts with Error Capture Off, only turning it ON when necessary...

Set Error Capture [ on ]

Enter Find Mode

Set Variable [ Get ( lasterror ) ]

Set Error Capture [ off ]

That way, FMP will alert you to all of the *unexpected* error conditions. It's the unexpected ones that cause problems.

Second thing, the find criteria are initially stored in variables. No problems there... as long as the window in on the right TO and in browse mode. (I've been bitten by the "in the wrong mode" problem before.)

Lastly, are the date field *really* date fields?

[dansmith65]

where is the Set Error Capture [ on ] step located?

Near the top as you expected. The full script is attached as a text document.

If it's right at the beginning of the script, I'd suggest not doing it this way. Instead, always run scripts with Error Capture Off, only turning it ON when necessary...

That makes alot of sense! Unfortunatly, I built my entire solution with this script step at the beginning of each script. I am going to re-do as you suggested on this script and see if it uncovers anything.

as long as the window in on the right TO and in browse mode.

This has been covered. It's definetly another great piece of advice to keep in mind when using variables. Although, I Modified the script to include an Enter Browse Mode step - just to be extra sure.

Lastly, are the date field *really* date fields?

Yes they are. just double checked.

I attached a new text document with the updated script.

JOB__Print__ReleaseForm2.txt

[Fitch]

Try breaking the name and date into separate searches. I.e., do a Find on the name, and then if records are found, do a Constrain Found Set on the date. Or v. versa. That way you can capture the errors separately and see if the problem is specific to one of the fields.

[dansmith65]

I thought this was a really good idea, but when I went to do it, I noticed that I cant! at least as far as I know.

The date I am searching for is stored in the currently selected record at the beginning of the script. In the script, I copy it to a variable then use "Set Field" to copy back to the field in find mode. This cant be done using constrain found set, can it? If there was a way, I'd love to know.

Alternatly, I could search for the name, then if records are found, search for the name and date. Not quite the same, but might give me some more information.

[Fitch]

Constrain and Extend can be scripted just like a normal Find:

Enter Find Mode

Set Field

Constrain Found Set

I was suggesting doing two separate Finds in the same script. If you're running two separate scripts, you could either stash the date in a global variable or global field for use in the second script.