BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Non Nesting Transactions

 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> C++ Builder Databases (Desktop)
View previous topic :: View next topic  
Author Message
Chris
Guest





PostPosted: Wed Oct 01, 2003 9:40 pm    Post subject: Non Nesting Transactions Reply with quote



Imagine if you will:

User opens Form1 and changes some data (which automatically starts a
transaction) but before commiting the changes he opens Form2 and changes
data (again automatically starting a transaction (which I guess is
considered nested)) but before commiting this he opens Form3 starting a new
transaction ......... Now the user accept changes in FormN......, Form3 and
Form2 but realises that he has messed up the data on Form1 so decides not to
save changes.

As I understand transactions the rollingback on Form1 will rollback the
already commited transactions on Form2, Form3...FormN, is this correct?

More to the point is there any way I can use the above model but start new
transactions that are independent of each other?

Cheers

Chris

PS Just to clarrify, code in the forms start the transactions when it is
detected that data has changed, this is because tracking changes with the
aim of performing a batch update on the forms data would be a massive job.


Back to top
Jayme Jeffman Filho
Guest





PostPosted: Fri Oct 03, 2003 5:19 pm    Post subject: Re: Non Nesting Transactions Reply with quote



Hi Chris,

The StartTransaction() is a TDatabase method which begins a transaction. If
you're using explicit transactions control, calling the StartTransaction
method, and the database on Forms 1, 2, 3.. are the same, the application
will raise an exception when you call StartTransaction() for the second time
without ending the previous one. So you can and should check if the Database
is in transaction mode through the TDatabase::InTransaction property and
make sure there is not any opened transaction before open a new one. BDE
does not support nested transactions, you can have a single one, so the
first call to the TDatabase::Rollback() or TDatabase::Commit() methods it
will end the current transaction no matter it has begun on another form
command.

It is a good advice do not allow the user open another database entry form
until he or she has done the task on the opened form.

Different users can update the same database tables as long as they are
working on different machines and the database instance is not the same.

HTH

Jayme.


"Chris" <chris (AT) REMOVEchrischfmousey (DOT) karoo.co.uk> wrote

Quote:
Imagine if you will:

User opens Form1 and changes some data (which automatically starts a
transaction) but before commiting the changes he opens Form2 and changes
data (again automatically starting a transaction (which I guess is
considered nested)) but before commiting this he opens Form3 starting a
new
transaction ......... Now the user accept changes in FormN......, Form3
and
Form2 but realises that he has messed up the data on Form1 so decides not
to
save changes.

As I understand transactions the rollingback on Form1 will rollback the
already commited transactions on Form2, Form3...FormN, is this correct?

More to the point is there any way I can use the above model but start new
transactions that are independent of each other?

Cheers

Chris

PS Just to clarrify, code in the forms start the transactions when it is
detected that data has changed, this is because tracking changes with the
aim of performing a batch update on the forms data would be a massive job.





Back to top
Chris
Guest





PostPosted: Sat Oct 04, 2003 11:16 pm    Post subject: Re: Non Nesting Transactions Reply with quote



Thanks for the info, it stopped me from continuing developing what would
have been a flawed process.

Chris


"Jayme Jeffman Filho" <jjeffman (AT) cpovo (DOT) net> wrote

Quote:
Hi Chris,

The StartTransaction() is a TDatabase method which begins a transaction.
If
you're using explicit transactions control, calling the StartTransaction
method, and the database on Forms 1, 2, 3.. are the same, the application
will raise an exception when you call StartTransaction() for the second
time
without ending the previous one. So you can and should check if the
Database
is in transaction mode through the TDatabase::InTransaction property and
make sure there is not any opened transaction before open a new one. BDE
does not support nested transactions, you can have a single one, so the
first call to the TDatabase::Rollback() or TDatabase::Commit() methods it
will end the current transaction no matter it has begun on another form
command.

It is a good advice do not allow the user open another database entry form
until he or she has done the task on the opened form.

Different users can update the same database tables as long as they are
working on different machines and the database instance is not the same.

HTH

Jayme.


"Chris" <chris (AT) REMOVEchrischfmousey (DOT) karoo.co.uk> wrote in message
news:3f7b49e8$1 (AT) newsgroups (DOT) borland.com...
Imagine if you will:

User opens Form1 and changes some data (which automatically starts a
transaction) but before commiting the changes he opens Form2 and changes
data (again automatically starting a transaction (which I guess is
considered nested)) but before commiting this he opens Form3 starting a
new
transaction ......... Now the user accept changes in FormN......, Form3
and
Form2 but realises that he has messed up the data on Form1 so decides
not
to
save changes.

As I understand transactions the rollingback on Form1 will rollback the
already commited transactions on Form2, Form3...FormN, is this correct?

More to the point is there any way I can use the above model but start
new
transactions that are independent of each other?

Cheers

Chris

PS Just to clarrify, code in the forms start the transactions when it is
detected that data has changed, this is because tracking changes with
the
aim of performing a batch update on the forms data would be a massive
job.







Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> C++ Builder Databases (Desktop) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.