| Subject | Re: [IBO] TIBOQuey and TIB_Cursor |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-05-24T08:55:45Z |
At 08:38 AM 24/05/2004 +0000, you wrote:
will simply be committed, along with any pending (posted) DML requests
related to them. Of course, once the transaction is committed, the data in
your IBOQuery buffer is invalid, since it's no longer associated with any
transaction. IB_Cursor doesn't have a buffer (other than the row buffer)
so only the current row is invalid.
Performance effect? nothing unusual: you always need to refresh after a
hard commit. IBO has various CommitAction tricks to condition where the
buffer cursor will be after a Commit occurs.
If the statements are in a different transaction, they won't be affected by
your Commit, since their context is determined by the transaction that they
are in.
Helen
>HiIf those statements are inside the transaction that you commit, then they
>
>I use several TIBOQuey and TIB_Cursor.
>
>Does it have any influence (Performance, Transactions etc) on the
>system (both on client side and on server side) if I have:
>
>1.
>A TIBOQuery opened when I do a COMMIT ?
>
>
>2.
>A TIB_Cursor opened when I do a COMMIT ?
will simply be committed, along with any pending (posted) DML requests
related to them. Of course, once the transaction is committed, the data in
your IBOQuery buffer is invalid, since it's no longer associated with any
transaction. IB_Cursor doesn't have a buffer (other than the row buffer)
so only the current row is invalid.
Performance effect? nothing unusual: you always need to refresh after a
hard commit. IBO has various CommitAction tricks to condition where the
buffer cursor will be after a Commit occurs.
If the statements are in a different transaction, they won't be affected by
your Commit, since their context is determined by the transaction that they
are in.
Helen