Icon View Incident Report

Serious Serious
Reported By: Gordon Turner
Reported On: 7/28/2007
For: Version 1.05 Build 1
# 2433 Calling FlushBuffers Method While in a Transaction Causes Premature Commit

I've been trying out a new architecture for my application. All of the database functionality is contained in a COM object. I pass SQL strings or other record specific variables to the COM object where the tables are accessed, data fetched, records updated, etc. Data results are passed back in variant arrays which are handled by the classes, so the program has no access whatsoever to the tables directly. The COM object is created once at the beginning of the application and nowhere else.

Here is the behavior I'm seeing. I call the COM object to start a transaction using the EmptyEDBStringsArray parameter...

if not AppDBDataMod.AppDB.InTransaction then begin
AppDBDataMod.AppDB.StartTransaction(EmptyEDBStringsArray);

and then add a master record to Table A and detail records to Table B (through separate calls to the COM object for each record). Before adding the detail records to Table B (because they can be added in more than one way) I check to see if a transaction has already been started by calling an InTransaction function in the COM object...

Result := AppDBDataMod.AppDB.InTransaction;

and if not I call the COM object to start one. At the end of the updates I check where the transaction was started and call the COM object from the appropriate place to perform the Commit...

if AppDBDataMod.AppDB.InTransaction then
AppDBDataMod.AppDB.Commit(True);

As I'm debugging my code, my expectation was that if I cancelled execution of the program before the Commit then all the changes would be rolled back. But what happens is that each table change passed to the COM object is performed immediately and nothing is rolled back. As soon as the table change is executed from within the COM object, the results
are visible within EDBManager, even though I "know" a transaction has been started as the InTransaction method returns True as I continue with the processing.


Comments Comments and Workarounds
The issue was that the FlushBuffers method was being called after each Post call, thus causing the premature commit. The workaround is to call FlushBuffers only if the database is not in a transaction, which can be checked via the InTransaction property of the TEDBQuery, TEDBTable, or TEDBStoredProc Database property.


Resolution Resolution
Fixed Problem on 7/30/2007 in version 1.05 build 2


Products Affected Products Affected
ElevateDB VCL Client-Server
ElevateDB VCL Client-Server with Source
ElevateDB VCL Standard
ElevateDB VCL Standard with Source
ElevateDB VCL Trial

Image