A
Akhil
What is the philosophy of putting transaction code in the middle tier vs DB
stored proc?
stored proc?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
S
Scott Allen
The rule of thumb is to keep transactions as short as possible. With
that theory you can try to keep all trasactions inside stored
procedures, but there are always exceptions to the rule. You have to
do what works best for your application.
that theory you can try to keep all trasactions inside stored
procedures, but there are always exceptions to the rule. You have to
do what works best for your application.
M
Michel Walsh
Hi,
In addition to Scott's comment, a transaction in a sp can only cover the
data in that database, while being at another level, the transaction can
include non-database objects in the transaction (like COM+ transaction
does), where the database is then another object implied in the transaction,
rather than the coordinator of the transaction...
Hoping it may help,
Vanderghast, Access MVP
In addition to Scott's comment, a transaction in a sp can only cover the
data in that database, while being at another level, the transaction can
include non-database objects in the transaction (like COM+ transaction
does), where the database is then another object implied in the transaction,
rather than the coordinator of the transaction...
Hoping it may help,
Vanderghast, Access MVP
T
Thomas
Well, not only that, putting transaction into your stored procedures puts
significant business logic into the stored procedure. Imagine you have an
Person object that contains a Persons collection which might represent
contacts for the top-level Person. While you could hack together a stored
procedure that would allow you to save the top level object and it's child
objects, imagine that you later get a Company object with a Persons
collection. Now you have to replicate the stored procedure code you used in
the first situation to every other similar siutation. Blah!
IMHO, transaction code should *always* be in the business tier.
Tom
significant business logic into the stored procedure. Imagine you have an
Person object that contains a Persons collection which might represent
contacts for the top-level Person. While you could hack together a stored
procedure that would allow you to save the top level object and it's child
objects, imagine that you later get a Company object with a Persons
collection. Now you have to replicate the stored procedure code you used in
the first situation to every other similar siutation. Blah!
IMHO, transaction code should *always* be in the business tier.
Tom