Subject | Re: [IBO] Transaction Oddities |
---|---|
Author | Helen Borrie |
Post date | 2002-08-23T07:53:40Z |
At 09:25 AM 23-08-02 +0200, you wrote:
ib_transaction property to your persistent transaction object, you can set
the properties at design time. You can set the default transaction's
properties at run time, which is often what you want to do anyway.
of the transaction. Just make sure that you test to see that the
transaction isn't already started; or, better, isolate your import into a
separate transaction.
is done via CommitRetaining, the datasets *do* get closed and
reopened. What happens to the data in the client buffers depends on their
CommitAction setting. You probably have their CommitAction set to caClose,
which leaves them closed after the commit. Check the TIB_CommitAction type
in the help file to look for a more suitable one if you want your datasets
to "stay open".
Don't be tempted to use CommitRetaining for your batch import. Because it
retains the original cursor after its commit, it has its value when you are
doing row-by-row interactive stuff in the GUI. But it prevents garbage
collection; and a batch insert isn't under cursor control so you'll get
the untoward effects without gaining any benefit.
Helen
>Ok, so I have an IB_Connection and an IB_Transaction. The Transaction linksYou can, but you don't need to. One "advantage" is that, if you set the
>to the Connection component via the IB_Connection property.
>
>Ques. 1 - Do I need to link the DefaultTransaction property of the
>IB_Connection to the IB_Transaction component?
ib_transaction property to your persistent transaction object, you can set
the properties at design time. You can set the default transaction's
properties at run time, which is often what you want to do anyway.
>The IB_Transaction is configured as follows: -That's fine - StartTransaction overrides Autocommit=True for the duration
>
>AutoCommit True
>Isolation tiCommitted
>LockWait False
>RecVersion True
>ServerAutoCommit False
>
>For general inserts and updates I am not issuing StartTransaction or Commit
>statements - I'm assuming that this happens automatically.
>
>However, There are times when I'm doing a batch type input or update where I
>want control the transaction myself so that I can RollBack if necessary. I
>am doing one such update where I import a a Header Record and all its detail
>records - the process is bound by a StartTransaction - Committ (with a
>rollback on failure).
of the transaction. Just make sure that you test to see that the
transaction isn't already started; or, better, isolate your import into a
separate transaction.
>Ques. 2 - Why is it that upon issuing the COMMIT my datasets are closed???Commit actually kills the database cursors; and really, unless the commit
>Rather odd behaviour but thats what happens!
is done via CommitRetaining, the datasets *do* get closed and
reopened. What happens to the data in the client buffers depends on their
CommitAction setting. You probably have their CommitAction set to caClose,
which leaves them closed after the commit. Check the TIB_CommitAction type
in the help file to look for a more suitable one if you want your datasets
to "stay open".
Don't be tempted to use CommitRetaining for your batch import. Because it
retains the original cursor after its commit, it has its value when you are
doing row-by-row interactive stuff in the GUI. But it prevents garbage
collection; and a batch insert isn't under cursor control so you'll get
the untoward effects without gaining any benefit.
Helen