This behavior appears to be way too weird for me. I have a stored
procedure that runs multiple transactions, and in each one it updates
several records on several tables (like any normal transaction
does...). Then I run this procedure with dbaccess, interrupts with
ctrl-c and gets this (names changed for obvious reasons):
user@[EMAIL PROTECTED]
dbaccess db1 <<XXX
> EXECUTE PROCEDURE some_procedure(10686,4700000)
> XXX
Database selected.
213: Statement interrupted by user.
Error in line 1
Near character position 57
Warning:Data Commit is a result of an unhandled exception in TXN PROC/
FUNC/TRI
Data committed.
Database closed.
user@[EMAIL PROTECTED]
effect of this is, of course, to screw up the results of the
transaction, as not all tables were updated. I found this out when I
ran teh procedure again with different parameters and got this (names
changed again):
user@[EMAIL PROTECTED]
dbaccess db1 <<XXX
> EXECUTE PROCEDURE temp_procedure(10686,5015362)
> XXX
Database selected.
239: Could not insert new row - duplicate value in a UNIQUE INDEX
column (Unique Index:ix_client_req_pk).
100: ISAM error: duplicate value for a record with unique key.
Error in line 1
Near character position 1
Warning:Data Commit is a result of an unhandled exception in TXN PROC/
FUNC/TRI
Data committed.
Database closed.
which is even worse: an error causes commit! is this a strange new
behavior of cheetah? I was under the impression that an incomplete
transaction will always rollback when the session is disturbed. Am I
wrong?
Zachi
|
