On 10-5-2019 08:18, Fulvio Senore mailing@... [firebird-support] wrote:

>
>
> Il 09/05/2019 18:01, Thomas Steinmaurer ts@...
> [firebird-support] ha scritto:
>>> I have a program that uses Firebird 2.1. Most installation use the
>>> embedded version so I prefer to stick with 2.1 since it does all I need.
>>>
>>> I have a question about transactions: if I start a transaction, I add or
>>> modify some data, then the program gets an exception and it crashes,
>>> what happens to the transaction?
>>>
>>> I was believing that if the program terminates without calling commit or
>>> rollback, then the transaction is automatically rolled back.
>>>
>>> Now a customer had a problem that can be explained if the transaction is
>>> not rolled back, but the data changes remained in the database even if
>>> commit was not called because the program crashed before calling it.
>>>
>>> Can anybody explain if changed data in this situation remains in the
>>> database of is it rolled back?
>>
>> Data changes, which did not get acknowledged by either COMMIT or COMMIT
>> RETAINING should never get permanently persisted.
>>
>> Any chance that you are using your client access components in auto
>> commit mode?
>>
>>
> Thank you for your answer. I am using IBPP with C++ so auto commit
> should not be a problem.
>
> I made some research and I found this in the Firebird book:
>
> "NOTE Calls from the client to COMMIT or to ROLLBACK are the only
> possible ways to end a transaction. A failure to commit does not cause
> the server to roll back the transaction."
>
> On the other hand I made some tests using the debugger: I stopped the
> program before committing the transaction and I did not find any
> modified data in the database.
>
> I am confused.

The data isn't committed, so it isn't visible to any other transaction.
If a connection is closed with an active transaction, the transaction
will eventually be rolled back by Firebird. See also "“Dead”
transactions" in the Firebird book.

Mark
--
Mark Rotteveel