On May 4, 2:45=A0am, Zachi <zklop...@[EMAIL PROTECTED]
> wrote:
> 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]
=A0dbaccess db1 <<XXX
>
> > EXECUTE PROCEDURE some_procedure(10686,4700000)
> > XXX
>
> Database selected.
>
> =A0 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]
>
> the 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]
=A0dbaccess db1 <<XXX
>
> > EXECUTE PROCEDURE temp_procedure(10686,5015362)
> > XXX
>
> Database selected.
>
> =A0 239: Could not insert new row - duplicate value in a UNIQUE INDEX
> column (Unique Index:ix_client_req_pk).
>
> =A0 100: ISAM error: =A0duplicate 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
Zachi,
this is not cheetah dependent, this is dbaccess' default behaviour.
It bit me a few weeks ago so I learned my lesson.
ex****t DBACCNOIGN=3D1
in your environment is your friend. It stops dbaccess transaction
execution and rolls it back.
Check the manuals for the details.
Regards
Davorin
|
