Hi,
Is it good to have two transaction i.e two begin/commit in one SP.
like
beging
update..
commit
begin
update...
commit.
any performance improvements in any case or otherwise..If those two updates can be commited or rolled back independently from one
another, then your solution is OK.
But if they should be treated as a single atomic unit of work, you should
either enclose them into a single transaction (be it each in its own nested
trasaction or not), and make sure they are committed (or rolled back) as a
single unit of work (i.e. if one needs to be rolled back, the other either
never begins or is rolled back).
Other than that, based on your post, I see no problem. Unless this is your
entire procedure, in which case I see a gazzillion of them. :)
ML|||hi Sunny
This depends on your requirement. You can have 2 transactions in a SP.
If u have 2 different sets of queries, u can group them into two different
queries
best Regards,
Chandra
http://chanduas.blogspot.com/
http://www.SQLResource.com/
---
"Sunny" wrote:
> Hi,
> Is it good to have two transaction i.e two begin/commit in one SP.
> like
> beging
> update..
> commit
> begin
> update...
> commit.
> any performance improvements in any case or otherwise..
Sunday, February 12, 2012
Begin tran/commit
Labels:
commit,
commitbeginupdate,
database,
improvements,
likebegingupdate,
microsoft,
mysql,
oracle,
performance,
server,
sql,
tran,
transaction
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment