How to prevent auto-commit using ApplyUpdates?
Andreas Krügersen
Hi all,
Is there any way to prevent my TClientDataSet from automatically commmiting
the
transaction when calling ApplyUpdates? I'm using a TOracleSession and a
TOracleDataSet in the app server.
I've already set TOracleDataSet.CommitOnPost = false and
TOracleSession.AutoCommit = false, but that doesn't seem to work.
I'm running out of options here...
thx in advance
Andreas Krügersen
Constantine Yannakopoulos
| Is there any way to prevent my TClientDataSet from automatically
| commmiting the transaction when calling ApplyUpdates? I'm using a
| TOracleSession and a TOracleDataSet in the app server.
It is not a good idea to leave a transaction open outside the context
of a single server method, especially if the program returns control to
the user before the transaction is committed or rolled baxk.
Implementing such long transactions (as they are called in my company's
lingo, and the term "long" has little to do with time) is a reason
enough to get yourself fired <g>.
However, the provider does not start or commit the transaction during
ApplyUpdates if it finds that there was already an open transaction
before the method was called. So you can manually call StartTransaction
on your database connection component before you call ApplyUpdates and
Commit it manually whenever you want.
--
Constantine
Andreas Krügersen
> However, the provider does not start or commit the transaction during
> ApplyUpdates if it finds that there was already an open transaction
> before the method was called. So you can manually call StartTransaction
> on your database connection component before you call ApplyUpdates and
> Commit it manually whenever you want.
>
That's not as easy as it may seem. As far as I know you cannot explicitly
start an Oracle Transaction. It is (re)started implicitly everytime you
commit the current transaction. But that means the provider should not
commit anything because the transaction is
always open (if the provider really behaves like you said)
> It is not a good idea to leave a transaction open outside the context
> of a single server method, especially if the program returns control to
> the user before the transaction is committed or rolled baxk.
>
That's a point, but I have a reason to do so. I'm pretty sure that there
is a much simpler solution but I haven't found it yet.
I have two TClientDataSets with updated rows. There can be new rows and
there can be rows deleted. I want to apply both but they are mutually
dependent on each other. If there are new rows I need to apply Set A first,
if there have been rows deleted I need to apply Set B first. Problem is,
when both has happened, there will always be an integrity constraint that
fires.
So I wanted to turn the constraints off temporarily (which works fine)
then apply both sets and turn them on again. Problem is, because
ApplyUpdates
does a commit, the constraints are reenabled after the first ApplyUpdates
because the transaction has ended!
So I would do a manual commit myself if I could somehow turn off this
auto-commit feature.
But as I said, I guess there is a much simpler solution...
vavan
<krueg...@projecteam.de> wrote:
>I have two TClientDataSets with updated rows. There can be new rows and
...
>But as I said, I guess there is a much simpler solution...
looks like all you need is to use midess pack which let you pass an
array of deltas onto appserver and wrap them all in a single
transaction
--
Vladimir Ulchenko aka vavan
Andreas Krügersen
>
> looks like all you need is to use midess pack which let you pass an
> array of deltas onto appserver and wrap them all in a single
> transaction
Sounds good. But what is "midess pack"?
Dave Rowntree
>Sounds good. But what is "midess pack"?
MidEss stands for MIDAS Essentials pack. It's getting a bit long in
the tooth now but still mainly relevant.
http://sourceforge.net/projects/midess/
--
Dave Rowntree
Dave Rowntree
--
Dave Rowntree
Ralf Jansen
> Constantine Yannakopoulos wrote:
>
> I have two TClientDataSets with updated rows. There can be new rows and
> there can be rows deleted. I want to apply both but they are mutually
> dependent on each other. If there are new rows I need to apply Set A first,
> if there have been rows deleted I need to apply Set B first. Problem is,
> when both has happened, there will always be an integrity constraint that
> fires.
> So I wanted to turn the constraints off temporarily (which works fine)
> then apply both sets and turn them on again. Problem is, because
> ApplyUpdates
> does a commit, the constraints are reenabled after the first ApplyUpdates
> because the transaction has ended!
> So I would do a manual commit myself if I could somehow turn off this
> auto-commit feature.
>
> But as I said, I guess there is a much simpler solution...
>
You know about nested Datasets ? If not take a look at the
Demos\Midas\MstrDtl Demo or take a look in the Delphi Helpfiles.
In a nested Dataset scenario the Datasetprovider will handle correct
order of insert and deletes for you.