Subject | Re: [IBO] Database Commitment Problem. |
---|---|
Author | Helen Borrie |
Post date | 2006-11-01T22:34:13Z |
At 04:34 AM 2/11/2006, you wrote:
according to the corresponding VCL implementation. However, when you
have depended on strange workarounds such as the above, the bets tend
to be off.
1. Check whether you have inadvertently got Autocommit set to true
on your IBODatabase's transaction...
2. Given the cross-matching of datasets with database connections
you discovered with your other problem, clear the DatabaseName
property on the offending datasets and explicitly select the values
of their IB_Connection and IB_Transaction properties.
3. All that stuff you are doing in your workaround code is overkill
and could lead to things happening in the wrong sequence (even under
the BDE, actually...). In particular, I'd be worried about work
that's already in a transaction getting rolled back
unintentionally. In the statement object's BeforePost (for a
dataset) or BeforeExecute (for a DML statement) It's sufficient to
use the logic
with MyQuery do
begin
if IB_Transaction.TransactionState = tsNone then
IB_Transaction.StartTransaction;
try
DoWhatever;
except
HandleYourException;
end
end;
4. Make sure that DbTables is not in your uses clause anywhere!! Db
should be there, DbTables not. If you are using any faulty
third-party controls, it's not uncommon to find that they conform to
their own rules and simply plonk everything into the uses clause of a form.
Helen
>In my IBOobjects conversion, I seem to have an intermittent problemAs a rule, the iboTDataset components are designed to behave
>with database transactions not commiting as they normally did using
>the BDE.
>I have one module with my Database_M as TIBODatabase and the following
>routines.
>
>procedure TDM_Database.Commitit(Num: Integer);
>begin
>// if not Database_Main.InTransaction then
>// showmessage(IntToStr(x) + ') Not in Transaction before commit');
> if Database_M.InTransaction then
> begin
> Database_M.Commit;
> end;
>end;
>
>procedure TDM_Database.Startit(Num: Integer);
>begin
>// if Database_Main.InTransaction then
>// showmessage(IntToStr(x) + ') Active in Transaction before Start.');
> if not Database_M.InTransaction then
> begin
> Database_M.StartTransaction;
> end;
>end;
>
>procedure TDM_Database.Backit(Num: Integer);
>begin
>// if not Database_Main.InTransaction then
>// showmessage(IntToStr(x) + ') Not in Transaction before RollBack');
> if Database_M.InTransaction then
> begin
> Database_M.RollBack;
> end;
>end;
>
>I generally call startit at the beginning of my database activity and
>commitit when I want to commit. I may call Startit twice in which
>case the routine does not call the database Start Transaction, since
>one has been called. Is there a possibility that the commit
>transaction is not being called. This is a problem that seems to be
>intermittent, so I am not sure what is happening except some
>transactions are not commiting to the database.
according to the corresponding VCL implementation. However, when you
have depended on strange workarounds such as the above, the bets tend
to be off.
1. Check whether you have inadvertently got Autocommit set to true
on your IBODatabase's transaction...
2. Given the cross-matching of datasets with database connections
you discovered with your other problem, clear the DatabaseName
property on the offending datasets and explicitly select the values
of their IB_Connection and IB_Transaction properties.
3. All that stuff you are doing in your workaround code is overkill
and could lead to things happening in the wrong sequence (even under
the BDE, actually...). In particular, I'd be worried about work
that's already in a transaction getting rolled back
unintentionally. In the statement object's BeforePost (for a
dataset) or BeforeExecute (for a DML statement) It's sufficient to
use the logic
with MyQuery do
begin
if IB_Transaction.TransactionState = tsNone then
IB_Transaction.StartTransaction;
try
DoWhatever;
except
HandleYourException;
end
end;
4. Make sure that DbTables is not in your uses clause anywhere!! Db
should be there, DbTables not. If you are using any faulty
third-party controls, it's not uncommon to find that they conform to
their own rules and simply plonk everything into the uses clause of a form.
Helen