RE: Anyway to get a .NET ExecuteNonQuery to ignore locked records?

I was going to advise SKIP LOCKED DATA as well, but alas it won't work prior
to 6.1.
Don't really know of a 'good' way to handle this scenario..... One thing
that comes to mind is to run a .Net job with commitment control and roll
back when you hit the error. I realize it's far from perfect but... Or
(shudder) write a stored procedure that updates record at a time and
monitors for failures on locked records.

As for detecting jobs with overly long commit boundaries, Centerfield has a
CHKCMTCTL utility (part of insure/MONITOR) that does that (disclaimer: I
work for Centerfield). It can proactively notify of jobs whose transaction
times exceed a max preconfigured by the administrator (i.e. you). Once you
find the offenders, you can have them correct the condition (unless politics
get involved :)).
I know of at least one large customer that heavily relies on this function
as overly long commit boundaries play havoc with their Save-While-Active
backups.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Re: Anyway to get a .NET ExecuteNonQuery to ignore locked records?

Ok, found out about the
SKIP LOCKED DATA

clause in 6.1....I don't suppose IBM has PTF'd that back to v5r4?

Charles

On Fri, May 22, 2009 at 3:26 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

All,

We've got a .NET application that updates a records in a table on the

iSeries.

Sometimes, it runs into a locked record and aborts.

Is there anyway to get it to ignore the locked records?

I'm thinking the best we could do would be to capture the eexception
and go on to the next statement, which would be any records that would
have been processed after the locked records will be skipped also.

I was thinking a continue handler in a SQL stored procedure would
help....but it apparently handler CONTINUEs with the next statement
and not any other records affected by the statement that had the
problem.  So the effect would be the same.

Note I am trying to track down the application on the iSeries that
aren't committing changes in a timely manner, but it's not easy.

Charles