BorlandTalk.com

Larry · Guest

I am investigating porting an existing BDE application to dbexpress. In
the current app, which usese cached updates, the client starts a
transaction, updates the server, then executes one or more stored
procedures which validate the data. If these send error messages to a
table, the transaction is rolled back. I'm trying to move this design
to dbx and Clientdatasets, but I cannot find an event which will allow
me to execute code within the transaction controlled by the applyupdates
procedure, or to roll it back. I don't have th source code open here,
but it appears that the entire transaction cycle takes place within the
protected InternalAppliedUpdate method. Are there any ideas, lessons,
or redesigns which someone can suggest?

Larry Lynn

Bill Todd · Guest

One possible solution is to explicitly start a transaction before
calling ApplyUpdates and explicitly commit or rollback the transaction
when you are done. dbExpress will use the existing transaction when you
call ApplyUpdates.

--
Bill (TeamB)
TeamB cannot answer questions received via email

Larry wrote:

Larry · Guest

Bill - Thanks for the quick response, BUT - I spent the morning reading
through the source, and I cannot find anywhere that ApplyUpdates will
use the existing transaction. Specifically, in TCustomSQLDataset it
checks this function:

function TCustomSQLDataSet.PSInTransaction: Boolean;
begin
Result := (FSQLConnection <> nil) and (FSQLConnection.InTransaction);
end;

SQLConnection.InTransaction goes here:

function TSQLConnection.GetInTransaction: Boolean;
begin
Result := FTransactionCount > 0;
end;

Ftransactioncount is initialized to 0, as a field of the class, and is
only incremented by StartTransaction. So I don't see how it will pick
up an existing transaction. Am I missing something (certainly possible)?

Larry Lynn

Bill Todd wrote:

Bill Todd · Guest

The SQLDataSet is not used in any way when you call ApplyUpdates. The
DSP creates and executes the SQL statements to apply the updates.

--
Bill (TeamB)
TeamB cannot answer questions received via email

Larry Lynn · Guest

Bill - The DSP ApplyUpdates calls InternalApplyupdates:

function TDataSetProvider.InternalApplyUpdates(const Delta: OleVariant;
MaxErrors: Integer;
out ErrorCount: Integer): OleVariant;
begin
CheckDataSet;
FTransactionStarted := not IProviderSupport(DataSet).PSInTransaction;
if FTransactionStarted then
IProviderSupport(DataSet).PSStartTransaction;
try
CheckResolver;
Resolver.FUpdateTree.InitData(DataSet);
try
Result := inherited InternalApplyUpdates(Delta, MaxErrors, ErrorCount);
finally
Resolver.FUpdateTree.InitData(nil);
end;
finally
if FTransactionStarted then
IProviderSupport(DataSet).PSEndTransaction((ErrorCount <= MaxErrors)
or (MaxErrors = -1));
end;
end;

The dataset in this line:
FTransactionStarted := not IProviderSupport(DataSet).PSInTransaction;

is a TSQLquery, and the IProviderSupport interface is implemented in the
TcustomSQLDataset ancestor, as detailed in my previous post. I just don't
see anywhere that it will use a preexisting transaction, or that I can
hook into an event within the open transaction.

Larry

Bill Todd · Guest

The way I read the code you posted it says if the dataset is not in a
transaction start one otherwise do not start one. If it does not start
a new transaction the changes will automatically take place in the
context of the existing transaction.

--
Bill (TeamB)
TeamB cannot answer questions received via email

Larry Lynn wrote:

Larry Lynn · Guest

Bill - The problem is that PSInTransaction looks at the transaction count
stored in the FTransactionCount var, and this is incremented or
decremented by the StartTransaction, Commit and Rollback methods of the
TSQLConnection - it does not appear to have anyway of detecting an open
transaction, or for me to pass it an ID for an open transaction. I'm going
to to some testing to see if I'm missing something, but this is how I read
the source.

Larry