On 10-5-2019 08:18, Fulvio Senore [email protected] [firebird-support] wrote: > > > Il 09/05/2019 18:01, Thomas Steinmaurer [email protected] > [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
