| Subject | Re: [IBO] BDE to IBO |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-04-22T06:53:24Z |
At 06:17 AM 22/04/2004 +0000, you wrote:
you haven't tied the SP's transaction to any particular transaction or
connection, so it's effectively attaching to the tibodatabase and creating
its own internal transaction. So - the iboquery is still looking at the
old view of database state.
Change the transaction isolation of the main query (the one embedded in the
ibodatabase) to tiReadCommitted. Then, you need only refresh the dataset
after the SP's transaction is committed.
I recommend dropping an explicit tibotransaction on the datamodule and
controlling ad hoc DML specifically with StartTransaction and
Commit/Rollback, so that your application always knows exactly when to
refresh datasets.
the baby with the bathwater" - you're destroying everything in order
refresh the view of one transaction! Rather, use the methods of the
transaction. You can access any transaction through the ib_transaction
property of the component that's using it.
If you want to mimic the BDE behaviour (one transaction for all) you
can; but don't leave it to fate for ad hoc transactions. I recommend
setting the ibodatabase's isolation to tiCommitted for interactive work,
and leaving it that way--that will solve your immediate problem and it's
also the smoothest way to keep things current for interactive users.
Helen
>I'm converting an application from IB6 (with BDE) to FB1.5 (with IBTake control of the transactions. What's going on here (I think) is that
>Objects) and have hit on a problem. (I ran a straight convert
>replacing TDatabase for TIBODatabase, TQuery for TIBOQuery and
>TStoredProc for TIBOStoredProc. etc) Problem:- I update a TDBEdit,
>which in turn Starts a Transaction, Executes a StoredProc and
>Commits, then closes and reopen the Query - but the data does not
>refresh.
you haven't tied the SP's transaction to any particular transaction or
connection, so it's effectively attaching to the tibodatabase and creating
its own internal transaction. So - the iboquery is still looking at the
old view of database state.
Change the transaction isolation of the main query (the one embedded in the
ibodatabase) to tiReadCommitted. Then, you need only refresh the dataset
after the SP's transaction is committed.
I recommend dropping an explicit tibotransaction on the datamodule and
controlling ad hoc DML specifically with StartTransaction and
Commit/Rollback, so that your application always knows exactly when to
refresh datasets.
>(When I check the data it has been updated.) On trying toA datamodule is only a container. Your solution is known as "throwing out
>locate the problem I found that if I Free then Re-Create the
>Datamodule used, then the data is refreshed OK.
the baby with the bathwater" - you're destroying everything in order
refresh the view of one transaction! Rather, use the methods of the
transaction. You can access any transaction through the ib_transaction
property of the component that's using it.
>Are there any setting in IBO which could cause this effect."Lack of" settings, I guess you'd say.
If you want to mimic the BDE behaviour (one transaction for all) you
can; but don't leave it to fate for ad hoc transactions. I recommend
setting the ibodatabase's isolation to tiCommitted for interactive work,
and leaving it that way--that will solve your immediate problem and it's
also the smoothest way to keep things current for interactive users.
Helen