IBM CLI #verifyNoError:infoType:hstmt:ifError:

[waynej]

In the 7/9/2003 edition of AbtIbmCliDatabaseConnection>>#verifyNoError:infoType:hstmt:ifError:, note the whileFalse: loop. It will remember the first error in 'sqlstate' which is used in creating the AbtError returned from the method. Remembering the first error sounds like a good idea in general, but:

See how http://publib.boulder.ibm.com/infocente ... ll1320.htm describes the 01S01 as an indicator of partial success or partial failure, where actual failure is the second error. So #verifyNoError:infoType:hstmt:ifError: does log that second error, but callers have no idea it happened.

My application runs on Windows and connects to a DB2 database. By hand I can lock a table to cause a DB2 lock timeout, and if the database is on Windows, I get sqlstate=57033. But if the database is on a mainframe, the 01S01 comes into play and because of the above, my code will get sqlstate=01S01. I do see the sqlstate=57033 logged but it's not in the AbtError.

You see, my code looks at AbtError instances and tries to decide whether the failure is something that should be retried (like connection errors or DB2 lock timeouts) versus something that should cause an abort immediately. So should I patch #verifyNoError:infoType:hstmt:ifError: to allow a second error to overwrite a 01S01? Or should my higher level code figure that if we get 01S01, it's probably something like a lock timeout so I should retry?

[tc]

Hello,

I read your message but I am not able to verify it against a mainframe.

In general, I would change the code that looks at AbtError and have it try and figure out if the problem is a lock timeout.

However, if you feel comfortable with your change and it gives you the behavior you want then use that.

It is very hard to give a hard fast answer in a situation like this, such as, 'use your change'.

If it were me, I would modify the higher level code first.

--tc