See your Transact-SQL reference for BEGIN TRAN and END TRAN.
Basically, it's a way to make sure that either *everything* in your batch of
(a dozen, two dozen, 2, whatever) SQL statements gets correctly executed, or
the db makes it look like nothing ever happened.
For instance, say I have to insert rows into 4 different tables every time I
want to add new products to my db. However, because of the way the schema
is arranged, I really need to have it all happen at once, instead of 4
seperate updates. (Say you have keys that rely on eachother or something
silly like that.) Also, if you are working in a multithreaded environment,
you have to worry about concurrency.
So, if one of my inserts fails for any of those reasons (or whatever other
reason) I need to remove the rows I added in the previous inserts so that my
db stays in a consistent state. This is why I would use a transaction. If
an error occurs while you are in the middles of a transaction, you can just
tell the db to pretend like you never even started the entire transaction.
Poof. Gone like magic. You don't have to manually remove the rows.
(Indeed, they aren't even there to be removed.)
Does that help?
-Rick
-----Original Message-----
From: Chad [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 07, 2000 3:05 PM
To: [EMAIL PROTECTED]
Subject: <CFTRANSACTION>
Can someone explain what the book means by "<CFTRANSACTION> implements
transaction,and rollback processing."???
What is roll back processing?
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
