Intermittent Script Step Failure

[MorFologist]

I have a problem with script steps occaisionally being skipped (on various scripts).

Hitting the script a second time always performs correctly. I can't repeat it with debugger or on demand.

FM9 cross platform users. FM9 Server Advanced Windows. The WAN connection is very slow and occasionally disconnects users, but LAN users have experienced this as well.

Is it possible for a bad network connection to cause this?

Or is it really possible to write a script that can misbehave (aside from obvious issues with record locking)?

I have found three scripts that have been reported as occasionally not working as expected (the italics portion fails)

Script A, Print: New Window, Omit all but current record, go to print layout based on a script parameter, set page setup via subscript based on OS, preview, print.

Script B, Print : New Window, set variables, new window from other table, find records based on variables, go to print layout based on a script parameter, sort, set page setup, preview, print.

In both cases, once in while, the script skips performing a step or two, seemingly the "find" and leaves the users previewing the top record of the table, or displaying all records instead of the expected found set.

Script C, New Record:Find related set by field A (value 123), sort by Field B (starter value of 1), add +1 to value of last record in set, field B. (result is pseudo serials of 123-1, 123-2, etc. Works 99 times out of 100, then once in a blue, it fails to do other than create the new record with the proper prefix but not having calculated the suffix, leaving several records labelled 123-1, 123-1).

Your thoughts welcome!

[mr_vodka]

Perhaps you should post the actual scripts themselves. Scripts do not normally skip steps.

[bcooney]

Yes, we need actual script steps, but in reading the OP's post, a couple of red flags went up for me.

Script A, Print: New Window, Omit all but current record, go to print layout based on a script parameter, set page setup via subscript based on OS, preview, print.

How do you omit all but current record? gtrr self-join? If you use Show All, Omit, Show Omitted, this can fail in multi-user environments.

Script B, Print New Window, set variables, new window from other table, find records based on variables, go to print layout based on a script parameter, sort, set page setup, preview, print.

New Window, set variables ($local?, $$global) New Window from other table, Huh? Another new window?

You can't find based on variables unless you're using Find, Set Field, Perform find construct, are you?

[mr_vodka]

I completely agree with you Barbara. I saw the same red flags but wanted to make sure before I suggested anything so the scripts are needed.

[MorFologist]

If you use Show All, Omit, Show Omitted, this can fail in multi-user environments.

Bingo! Didn't know that! I of course, wonder why, but I'll just redo this script to something less FM6ish so that's that for script A!

[comment]

See:

http://fmforums.com/forum/showtopic.php?tid/184454/tp/0/all/1/

[MorFologist]

Script B...

New Window, set variables ($local?, $$global) New Window from other table, Huh? Another new window?

You can't find based on variables unless you're using Find, Set Field, Perform find construct, are you?

Here is Script B. It selects from several reports based on several paramenters so I eliminated those segments assuming I am also creating a "doesn't always work in Multi-User Environment" situation in the Find portion here as well. I greyed the portion added recently that post dates the intermittent issue, which is that the Find fails, and all records are shown. I also added the ability to cancel the sort after discovering this issue (blue) in case the user experiences the "all records" result and needs to rerun the script:

Set Error Capture [ On ]

# Exit Script if not already in browse mode.

If [ Get (WindowMode ) = 0 ]

New Window [ Name: "Print Preview"; Height: 744; Width: 920; Top: 24; Left: 48 ]

Show/Hide Status Area [ Show ]

#

#FINANCE YCP Report

# Perform Find, coming from AB

If [ PatternCount(Get ( ScriptParameter );"ab") ]

Set Variable [ $year; Value:ANBUDGET::PlanYear ]

Set Variable [ $bu; Value:ANBUDGET::BusUnit_c ]

Go to Layout [ “reportfind_Finance_ycd” (Jobs_ab_byYCD) ]

Enter Find Mode [ ]

Set Field [ Jobs_ab_byYCD::FR_BusUnit_c; $bu ]

Set Field [ Jobs_ab_byYCD::PlanYear; $year ]

Perform Find [ ]

#

[color:gray]# 080720 adding alt currency

If [ PatternCount(Get ( ScriptParameter );"euro") ]

Go to Layout [ “report_JobYCD_Finance_Euro” (Jobs_ab_byYCD) ]

Else If [ PatternCount(Get ( ScriptParameter );"dollar") ]

Go to Layout [ “report_JobYCD_Finance_Dollar” (Jobs_ab_byYCD) ]

Else

Go to Layout [ “report_JobYCD_Finance_Pound” (Jobs_ab_byYCD) ]

[color:gray]End If

#

Perform Script [ “Pagesetup Horizontal by OS and Location” ]

[color:blue]Allow User Abort [ On ]

Sort Records [ Specified Sort Order: [color:blue]{...} [ Restore; No dialog ]

[color:blue]Allow User Abort [ Off ]

# Enter preview mode (paused) for user to review report

Enter Preview Mode [ Pause ]

#

# When user continues, provide a print dialog

Print [ Records being browsed; All Pages; Orientation: Portrait; Paper size: 8.26" x 11.69" ] [ Restore ]

#

Enter Browse Mode

Show/Hide Status Area [ Hide ]

Close Window [ Current Window ]

#

End If

Thanks!

[MorFologist]

Thanks! I'll update Script A and think about how this issue might apply to the other two scripts.

[bcooney]

I'm not seeing anything obvious in ScriptB. I'm specifically looking for context errors.

Set Variable [ $year; Value:ANBUDGET::PlanYear ]

Set Variable [ $bu; Value:ANBUDGET::BusUnit_c

OK, these two steps require that you are on a layout that is based on the ANBUDGET table occurrence. Also, that the record has values in PlanYear and BusUnit_c.

[MorFologist]

Those two values in Annual budget are always there to pick up - the AB record is is showing a portal of the data that the report will be built on so one can see there is data before printing. The problem is just once in a blue, that script fails to perform the find in the next table that is based on those two variables and uses all records. Click the script a second time and it works.

[bcooney]

the AB record is is showing a portal of the data

So, you might have a context issue? Is this ANBUDGET::PlanYear really the relationship to get to PlanYear. Mentioning a portal makes me think that you need the relationship that is used for the portal? (Why not be on the table in which PlanYear resides?)

[MorFologist]

AnnualBudget, aside from the three key fields, contains fields to store a value for the budget of each project type for the year. The portal/related table contains the same three key fields and details of each invoice. The report is a multi-part summarized report of actual expenses compared to budget.

I used the "store variable and enter into find" method so I can run this report from any of the other tables using this same report (i.e. from a Dept or Project view point).

This script works nearly all of the time, and I myself only saw it fail and use "all records" once for myself by luck and can't repeat the error, it always works the next time you hit the button. The idea of a multi-user environment causing a script to fail by the coincidence of a user locking, deleting or adding a record makes sense. I just can't see how that could effect a find based on set variables.

I suppose I can switch to moving to this found set by portal relationship, but then this report would have to be redone for the other tables to access (it's not a spider relationship). I would rather get to the bottom of the logic flaw so I can seek out and fix any script where I have inadvertently set up the potential for intermittent error.

[IdealData]

I read your Script B and logically it's all there, but if the user's privileges do not allow access to the specified layouts or fields then those script steps will fail. This also extends to field validations.

As your script has got error capture ON then you are suppressing the possible errors and are not testing for them in your script.

Why not disable the error capture and let the user's tell you what the fault is next time around.

It took me several years to find out why a script "intermittently" failed to switch layout. Like you, I suspected network speed - I was wrong!

I had a field validation that was failing but I used error capture ON in the script so I never saw the error. All became very clear when I turned the error capture OFF to expose the fault.

All fixed now!

Edited December 7, 2008 by Guest