Charles Lei writes:
|> We changed over to On-Line 4.10 UG1 from SE 4.10 UD2 on our SCO Unix
|> 3.2.4 486 Box. During the testing process everything worked great.
|> We decided to "go live" with it this past weekend but unfortunately in
|> the live environment (10 to 30 users), the save function of our FourGen
|> Order Entry application kept bombing out with the following group of
|> messages:
|>
|> SQL statement error number -240.
|> Could not delete a row.
|> SYSTEM error number -154.
|> ISAM error: Deadlock Timeout Expired - Possible Deadlock.
|>
|> Is this a manifestation of the infamous twin paradox problem? We've
|> increased the deadlock time out from 60 seconds to 300 seconds, but
|> this error kept occurring.
First of all, unless you are using I-STAR, the DEADLOCK_TIMEOUT value will
have no effect; it ONLY applies to distributed operations.
What I have to suspect you are experiencing is a "bug" (I quote it because
I have not looked it up in our bug tracking system to verify that it has
been designated a bug) that causes a lock timeout to return the error
code for a distributed deadlock timeout. If you have any statements like:
SET LOCK MODE TO WAIT 30
(or any number), when that time expires, an error is returned to your app,namely -154. What should be returned is a different error code
indicating that the lock wait timeout has expired - it has NOTHING to do
with deadlocks.
To "fix" your problem, you would have to increase your wait time or
catch an error return from any SQL statement that would wait for a lock and
deal with it.
Dave
Disclaimer: These opinions are not those of Informix Software, Inc.
**************************************************************************
"I look back with some satisfaction on what an idiot I was when I was 25,
but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney