This script is skipping records when I have a set of 10 or more :/

[dsghs]

This script goes through a found set of records and marks a field: 0

It works perfectly until there are more than 9 or so records. Then it skips maybe 2 of them. Then I have to run the script again to clean up the remaining records (it then successfully marks the ones it missed). It runs mostly through IWP if that makes any difference?

Thoughts appreciated!

[IdealData]

You'll need to post your script first.

[dsghs]

You'll need to post your script first.

It should be in the screenshot on the first post. Here it is as text:

Go to Record/Request/Page [First]

Loop

Set Field [inspection::inspectionClustered; 0]

Go to Record/Request/Page [Next; Exit after last]

End Loop

Perform Script ["GoToCluster"]

[eos]

Is the found set sorted, and if so, does the field you set appear in the sort order?

[bcooney]

Record lock issue? You have no check on that at all.

[comment]

Is the found set sorted, and if so, does the field you set appear in the sort order?

That's a red herring; a found set will NOT auto-sort while a script is running.

[eos]

No herrings involved; just plain ignorance

That's a red herring; a found set will NOT auto-sort while a script is running.

[dsghs]

Record lock issue? You have no check on that at all.

This might be an issue. I'll run the script a bunch on the client with 10+ records and see if I get a record lock notification.

[Vaughan]

Are there script triggers anywhere can might be bouncing things around?

Also you should be committing the record before going to the next.

[comment]

Also you should be committing the record before going to the next.

Why? Going to next record will commit the current record, if open.

[Vaughan]

Why? Going to next record will commit the current record, if open.

And if the record has validation?

[comment]

Unless you are suggesting to commit while skipping validation, there's still no difference. In any case, failing validation should break the flow - not skip a record or two.

Like Barbara, I would suggest fitting the script with some error-capture/logging procedure.

[bcooney]

For Example:

Go to Record/Request/Page [First]

Loop

Set Field [inspection::inspectionClustered; 0]

If (get (lasterror)≠0

// write this ID to a log

// exit script?

EndIf

Go to Record/Request/Page [Next; Exit after last]

End Loop

Perform Script ["GoToCluster"]

However, I would suggest rewriting the entire operation to be transactional if you need all records touched or if any one fails, then all edits roll back. See Todd Geist's blog.

[comment]

I think I would go for something like:

Loop

Set Field [ ... ]

Set Variable [ $log ; List ( $log ; SerialID & Char ( 9 ) & Get (LastError) ) ]

...

Then, after the mystery is solved, I would ask why records need to be marked in the first place.

[Vaughan]

The OP mentioned that this runs under IWP. Could the 10 record limit be hitting here?

[dsghs]

I think I would go for something like:

Loop

Set Field [ ... ]

Set Variable [ $log ; List ( $log ; SerialID & Char ( 9 ) & Get (LastError) ) ]

...

Then, after the mystery is solved, I would ask why records need to be marked in the first place.

If they are marked, they are kept on a list of "to do" records. If they are unmarked, they are not on the "to do" list. The "to do" list is for reports that still need to be printed and mailed to customers, billed through quickbooks (integration coming up :x). It's also to separate related records from other related records that I don't want to print. IE, these are inspection reports for units which belong to sites. If there are 6 units at a particular site and I only want to print reports on the first 2, then the 2 are marked and the other 4 are unmarked until i print the reports. Then I run this script which unmarks the 2.

The OP mentioned that this runs under IWP. Could the 10 record limit be hitting here?

I believe IWP list record max is 25, however it uses the next record step which shouldn't care if only 25 records are displayed, right?

[comment]

Marking records is always problematic, because of locking issues. If the marking is arbitrary (which is usually user-specific as well), then it's better to write out a list of the marked records - either into a field, or as records in a related table. If it's not arbitrary, then it's redundant, because the status can be determined from the other data.

In any case, I'd suggest you run the logging procedure first to determine the cause of failure.