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@db$ 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

Warningata Commit is a result of an unhandled exception in TXN PROC/
FUNC/TRI

Data committed.

Database closed.

user@db$




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@db3$ 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

Warningata 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

On May 4, 2:45*am, Zachi <zklop...@gmail.com> 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@db$ *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
>
> Warningata Commit is a result of an unhandled exception in TXN PROC/
> FUNC/TRI
>
> Data committed.
>
> Database closed.
>
> user@db$
>
> 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@db3$ *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
>
> Warningata 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.

export DBACCNOIGN=1

in your environment is your friend. It stops dbaccess transaction
execution and rolls it back.
Check the manuals for the details.

Regards

Davorin