I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible errors
and rollback all necessary data.
Over the last few days I've been trying to convert some of this code to
SQL Server stored procedures, but it seems to lack many of the benefits
of C# transactions - a lot of the errors don't seem to be trapped by the
SQL error trapping (e.g. if I do an update on a row that doesn't exist,
no rollback occurs and execution continues, if a table I am trying to
access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your transactions
in stored procedures rather than your .NET code, as there don't seem to
be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it! 11  12977 
Mike P wrote: Can anybody tell me what reasons there are for writing your transactions
in stored procedures rather than your .NET code, as there don't seem to
be any to me.
I can think of ...
Smaller and faster client applications
Changing of procedures whithout modifying client application
List goes on... :)
What do you mean by a C# transaction?
Are you talking about System.Enterpri seServices.Serv icedComponent? or
SqlConnection.B eginTransaction ?
or something else?
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<e4************ **@TK2MSFTNGP14 .phx.gbl>
I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible errors
and rollback all necessary data.
Over the last few days I've been trying to convert some of this code to
SQL Server stored procedures, but it seems to lack many of the benefits
of C# transactions - a lot of the errors don't seem to be trapped by the
SQL error trapping (e.g. if I do an update on a row that doesn't exist,
no rollback occurs and execution continues, if a table I am trying to
access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your transactions
in stored procedures rather than your .NET code, as there don't seem to
be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system ( http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004
[microsoft.publi c.dotnet.langua ges.csharp]
Mike,
Personally, I think that managing transaction state in your stored
procedures is a very, very bad idea. It limits how they can be used
elsewhere, and for the most part, are harder to maintain (as you have more
and more sp's calling each other, trying to maintain transaction state is a
pain).
I would recommend using EnterpriseServi ces for handling transaction
state. There are a number of reasons for this, the best one being easy
maintainability (you can turn transactions on and off with the flick of a
switch, or change their behavior). Another reason to handle this would be
because it offers the easiest translation path to Indigo.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
news:e4******** ******@TK2MSFTN GP14.phx.gbl... I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible errors
and rollback all necessary data.
Over the last few days I've been trying to convert some of this code to
SQL Server stored procedures, but it seems to lack many of the benefits
of C# transactions - a lot of the errors don't seem to be trapped by the
SQL error trapping (e.g. if I do an update on a row that doesn't exist,
no rollback occurs and execution continues, if a table I am trying to
access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your transactions
in stored procedures rather than your .NET code, as there don't seem to
be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Hi mrp:
As other have commented, error handling in stored procs is very
difficult to do - it tends to clutter up the TSQL quite a bit and it's
terribly easy to overlook a problem. It's an approach I try to avoid.
SQL 2005 has some improvements, but that's not here, and if you are
concerened about portability at all its not an option.
--
Scott http://www.OdeToCode.com
On Thu, 23 Sep 2004 06:44:40 -0700, Mike P
<mr*@telcoelect ronics.co.uk> wrote: I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible errors
and rollback all necessary data.
Over the last few days I've been trying to convert some of this code to
SQL Server stored procedures, but it seems to lack many of the benefits
of C# transactions - a lot of the errors don't seem to be trapped by the
SQL error trapping (e.g. if I do an update on a row that doesn't exist,
no rollback occurs and execution continues, if a table I am trying to
access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your transactions
in stored procedures rather than your .NET code, as there don't seem to
be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Are you talking about database transactions or something else? Database
transactions, i.e, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN, really should not
be used in the front-end application. You greatly increase your risk to
locking, blocking, inconsistent data, corrupt data, long running
transactions (which leads back to locking and blocking), uncommitted
transactions, and more. Transactions should be kept as short as possible to
keep database access clean. I take the totally opposite stance and say
transactions and typed sql statements (even though you didn't mention these
but they would go hand-in-hand with someone who was creating transactions in
the FE) should never exist in the front-end. I believe that the only access
from a front-end should be limited to executing stored procedures.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Mike,
Personally, I think that managing transaction state in your stored
procedures is a very, very bad idea. It limits how they can be used
elsewhere, and for the most part, are harder to maintain (as you have
more and more sp's calling each other, trying to maintain transaction
state is a pain).
I would recommend using EnterpriseServi ces for handling transaction
state. There are a number of reasons for this, the best one being
easy maintainability (you can turn transactions on and off with the
flick of a switch, or change their behavior). Another reason to
handle this would be because it offers the easiest translation path
to Indigo.
Hope this helps.
"Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
news:e4******** ******@TK2MSFTN GP14.phx.gbl... I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible
errors and rollback all necessary data.
Over the last few days I've been trying to convert some of this code
to SQL Server stored procedures, but it seems to lack many of the
benefits of C# transactions - a lot of the errors don't seem to be
trapped by the SQL error trapping (e.g. if I do an update on a row
that doesn't exist, no rollback occurs and execution continues, if a
table I am trying to access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your
transactions in stored procedures rather than your .NET code, as
there don't seem to be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Eric,
I would agree with you, transactions should not exist in the front end
(nor should dynamic SQL statements).
I am referring to the business layer. It is at this level that the
transactions should be controlled, and not by the programmer, but rather,
through the administrative tool (which gets the initial values from
attributes declared on the class).
The reason for this is that it allows for easy extenisibility in the
future. For example, say you have your transaction code in your stored
procedure now. Say that you have some piece of code that calls the stored
procedure. Later on, you have a requirement to write to a file when the
procedure completes, and to not write to the file when it fails. You would
want some sort of transaction manager to coordinate this. Of course, this
assumes that the file system is transactional (which it is in Longhorn).
The point is that when you start performing transaction management in
the resource that is being handled by the transacton, you severely limit the
other business processes that the resource can be included in. The file is
a simple case, but what about message queues? What about both queues and
emails? As you add more resources to the transaction state (outside of the
database), you need a way to abort them all.
It is because of the fact that I am going to make my business process
transactional, and not just my database operations transactional that I use
something like Enterprise Services, or the new Transaction model being
introduced in .NET 2.0. I believe that the mindset of the db being the only
transactional resource is on the way of being well behind us, and that
external entities are needed to control all of these resources, should
something fail while trying to perform operations on them.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in message
news:%2******** *******@TK2MSFT NGP14.phx.gbl.. . Are you talking about database transactions or something else? Database
transactions, i.e, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN, really should
not be used in the front-end application. You greatly increase your risk
to locking, blocking, inconsistent data, corrupt data, long running
transactions (which leads back to locking and blocking), uncommitted
transactions, and more. Transactions should be kept as short as possible
to keep database access clean. I take the totally opposite stance and say
transactions and typed sql statements (even though you didn't mention
these but they would go hand-in-hand with someone who was creating
transactions in the FE) should never exist in the front-end. I believe
that the only access from a front-end should be limited to executing
stored procedures.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Mike,
Personally, I think that managing transaction state in your stored
procedures is a very, very bad idea. It limits how they can be used
elsewhere, and for the most part, are harder to maintain (as you have
more and more sp's calling each other, trying to maintain transaction
state is a pain).
I would recommend using EnterpriseServi ces for handling transaction
state. There are a number of reasons for this, the best one being
easy maintainability (you can turn transactions on and off with the
flick of a switch, or change their behavior). Another reason to
handle this would be because it offers the easiest translation path
to Indigo.
Hope this helps.
"Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
news:e4******** ******@TK2MSFTN GP14.phx.gbl... I've been using C# transactions for a while and had no problems with
them. Using try catch blocks I can trap basically all possible
errors and rollback all necessary data.
Over the last few days I've been trying to convert some of this code
to SQL Server stored procedures, but it seems to lack many of the
benefits of C# transactions - a lot of the errors don't seem to be
trapped by the SQL error trapping (e.g. if I do an update on a row
that doesn't exist, no rollback occurs and execution continues, if a
table I am trying to access doesn't exist then the sproc crashes).
Can anybody tell me what reasons there are for writing your
transactions in stored procedures rather than your .NET code, as
there don't seem to be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
I do not believe we are discussing the same thing. I am strictly speaking
about SQL Server transactions and as you have indicated you are talking
about business layer "transactio ns." If the requirement were passed to the
DBA who was writing the stored procedure that File IO needs to take place,
he should kick it back and say that is outside the scope of the sql server
transaction.
SQL Server transactions are strictly for maintaining data integrity and
consistency, not to mention they give you a named place to restore to
instead of a datetime stamp. I believe you would benefit from not one, but
both, i.e., the data integrity transaction and the process integrity
transaction.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Eric,
I would agree with you, transactions should not exist in the front
end (nor should dynamic SQL statements).
I am referring to the business layer. It is at this level that the
transactions should be controlled, and not by the programmer, but
rather, through the administrative tool (which gets the initial
values from attributes declared on the class).
The reason for this is that it allows for easy extenisibility in
the future. For example, say you have your transaction code in your
stored procedure now. Say that you have some piece of code that
calls the stored procedure. Later on, you have a requirement to
write to a file when the procedure completes, and to not write to the
file when it fails. You would want some sort of transaction manager
to coordinate this. Of course, this assumes that the file system is
transactional (which it is in Longhorn).
The point is that when you start performing transaction management
in the resource that is being handled by the transacton, you severely
limit the other business processes that the resource can be included
in. The file is a simple case, but what about message queues? What
about both queues and emails? As you add more resources to the
transaction state (outside of the database), you need a way to abort
them all.
It is because of the fact that I am going to make my business
process transactional, and not just my database operations
transactional that I use something like Enterprise Services, or the
new Transaction model being introduced in .NET 2.0. I believe that
the mindset of the db being the only transactional resource is on the
way of being well behind us, and that external entities are needed to
control all of these resources, should something fail while trying to
perform operations on them.
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in message
news:%2******** *******@TK2MSFT NGP14.phx.gbl.. . Are you talking about database transactions or something else? Database
transactions, i.e, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN,
really should not be used in the front-end application. You greatly
increase your risk to locking, blocking, inconsistent data, corrupt
data, long running transactions (which leads back to locking and
blocking), uncommitted transactions, and more. Transactions should
be kept as short as possible to keep database access clean. I take
the totally opposite stance and say transactions and typed sql
statements (even though you didn't mention these but they would go
hand-in-hand with someone who was creating transactions in the FE)
should never exist in the front-end. I believe that the only access
from a front-end should be limited to executing stored procedures.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Mike,
Personally, I think that managing transaction state in your
stored procedures is a very, very bad idea. It limits how they can
be used elsewhere, and for the most part, are harder to maintain
(as you have more and more sp's calling each other, trying to
maintain transaction state is a pain).
I would recommend using EnterpriseServi ces for handling
transaction state. There are a number of reasons for this, the
best one being easy maintainability (you can turn transactions on
and off with the flick of a switch, or change their behavior). Another
reason to handle this would be because it offers the
easiest translation path to Indigo.
Hope this helps.
"Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
news:e4******** ******@TK2MSFTN GP14.phx.gbl...
I've been using C# transactions for a while and had no problems
with them. Using try catch blocks I can trap basically all
possible errors and rollback all necessary data.
Over the last few days I've been trying to convert some of this
code to SQL Server stored procedures, but it seems to lack many of
the benefits of C# transactions - a lot of the errors don't seem
to be trapped by the SQL error trapping (e.g. if I do an update on
a row that doesn't exist, no rollback occurs and execution
continues, if a table I am trying to access doesn't exist then the
sproc crashes). Can anybody tell me what reasons there are for writing
your
transactions in stored procedures rather than your .NET code, as
there don't seem to be any to me.
Any assistance would be really appreciated.
Cheers,
Mike
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Eric,
What I'm trying to say is that for any resource (DB included), if you
have the resource itself determine its transaction state, instead of a
transaction coordinator, it then becomes difficult to integrate that
resource into larger-scale transactions.
Because of that, I would recommend against handling transactions in SP
code, and have an external transaction coordinator (Enterprise
Services/COM+) handle it for you. Because SQL Server is registered as
having a resource manager, it can allow ES/COM+ to handle the transaction
management for it.
Ultimately, yes, ES/COM+ would call the resource manager for SQL server,
and issue the appropriate transaction commands, based on configuration. The
idea here isn't to lock those procedures into a pattern which would be
difficult to integrate other operations into.
So, for SQL server, or any resource that supports transactions, I would
never write a stored procedure that has transaction management code in it.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in message
news:Op******** ******@TK2MSFTN GP09.phx.gbl... I do not believe we are discussing the same thing. I am strictly speaking
about SQL Server transactions and as you have indicated you are talking
about business layer "transactio ns." If the requirement were passed to the
DBA who was writing the stored procedure that File IO needs to take place,
he should kick it back and say that is outside the scope of the sql server
transaction.
SQL Server transactions are strictly for maintaining data integrity and
consistency, not to mention they give you a named place to restore to
instead of a datetime stamp. I believe you would benefit from not one, but
both, i.e., the data integrity transaction and the process integrity
transaction.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Eric,
I would agree with you, transactions should not exist in the front
end (nor should dynamic SQL statements).
I am referring to the business layer. It is at this level that the
transactions should be controlled, and not by the programmer, but
rather, through the administrative tool (which gets the initial
values from attributes declared on the class).
The reason for this is that it allows for easy extenisibility in
the future. For example, say you have your transaction code in your
stored procedure now. Say that you have some piece of code that
calls the stored procedure. Later on, you have a requirement to
write to a file when the procedure completes, and to not write to the
file when it fails. You would want some sort of transaction manager
to coordinate this. Of course, this assumes that the file system is
transactional (which it is in Longhorn).
The point is that when you start performing transaction management
in the resource that is being handled by the transacton, you severely
limit the other business processes that the resource can be included
in. The file is a simple case, but what about message queues? What
about both queues and emails? As you add more resources to the
transaction state (outside of the database), you need a way to abort
them all.
It is because of the fact that I am going to make my business
process transactional, and not just my database operations
transactional that I use something like Enterprise Services, or the
new Transaction model being introduced in .NET 2.0. I believe that
the mindset of the db being the only transactional resource is on the
way of being well behind us, and that external entities are needed to
control all of these resources, should something fail while trying to
perform operations on them.
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in message
news:%2******** *******@TK2MSFT NGP14.phx.gbl.. . Are you talking about database transactions or something else? Database
transactions, i.e, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN,
really should not be used in the front-end application. You greatly
increase your risk to locking, blocking, inconsistent data, corrupt
data, long running transactions (which leads back to locking and
blocking), uncommitted transactions, and more. Transactions should
be kept as short as possible to keep database access clean. I take
the totally opposite stance and say transactions and typed sql
statements (even though you didn't mention these but they would go
hand-in-hand with someone who was creating transactions in the FE)
should never exist in the front-end. I believe that the only access
from a front-end should be limited to executing stored procedures.
Eric
Nicholas Paldino [.NET/C# MVP] wrote:
Mike,
Personally, I think that managing transaction state in your
stored procedures is a very, very bad idea. It limits how they can
be used elsewhere, and for the most part, are harder to maintain
(as you have more and more sp's calling each other, trying to
maintain transaction state is a pain).
I would recommend using EnterpriseServi ces for handling
transaction state. There are a number of reasons for this, the
best one being easy maintainability (you can turn transactions on
and off with the flick of a switch, or change their behavior). Another
reason to handle this would be because it offers the
easiest translation path to Indigo.
Hope this helps.
"Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
news:e4******** ******@TK2MSFTN GP14.phx.gbl...
> I've been using C# transactions for a while and had no problems
> with them. Using try catch blocks I can trap basically all
> possible errors and rollback all necessary data.
>
> Over the last few days I've been trying to convert some of this
> code to SQL Server stored procedures, but it seems to lack many of
> the benefits of C# transactions - a lot of the errors don't seem
> to be trapped by the SQL error trapping (e.g. if I do an update on
> a row that doesn't exist, no rollback occurs and execution
> continues, if a table I am trying to access doesn't exist then the
> sproc crashes). Can anybody tell me what reasons there are for writing
> your
> transactions in stored procedures rather than your .NET code, as
> there don't seem to be any to me.
>
>
> Any assistance would be really appreciated.
>
>
> Cheers,
>
> Mike
>
>
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!
My gut reaction is "I don't like it." That said, I am not an expert on
Enterprise Services or the DNF 2.0 Transaction model. I feel that this
external transaction coordinator (ETC) would cause me performance problems
in my sql server because (if I am understanding it properly) the ETC would
begin a transaction and say, start some process (transaction), get data from
disparate sources, write a text file, send data to a web service, more,
more, more, then some element bombs out and the ETC says "OK let's remain
consistent, roll everything back!". But the item that bombed out had a
timeout error at 20 seconds, so I take it that my sql server portion, which
was an update on a commonly used table, which happened to update enough rows
that the lock was escalated from a row lock to a table lock, also had to
wait for these 20 seconds (plus other elemental transaction times) before
it's transaction was rolled back. Meanwhile, my users trying to enter
orders got blocked.
I believe the purpose of the ETC is probably for business "consistenc y" and
I'm all for that - don't get me wrong, I'm all about the consistency :-) ,
but it probably comes at a performance price, which I see happening when you
take the database-transaction away from the database and you make it no
longer dependent on the DML (data modification language, i.e., the inserts,
updates, and deletes) and you make it dependent on the business process
instead.
If you could guarantee that the ETC waits on the sql server transaction as
the last process I could be convinced, but I don't see how you get scalable
and properly performing applications if your database is forced to wait on
other non-sql processes.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Eric,
What I'm trying to say is that for any resource (DB included), if
you have the resource itself determine its transaction state, instead
of a transaction coordinator, it then becomes difficult to integrate
that resource into larger-scale transactions.
Because of that, I would recommend against handling transactions
in SP code, and have an external transaction coordinator (Enterprise
Services/COM+) handle it for you. Because SQL Server is registered as
having a resource manager, it can allow ES/COM+ to handle the
transaction management for it.
Ultimately, yes, ES/COM+ would call the resource manager for SQL
server, and issue the appropriate transaction commands, based on
configuration. The idea here isn't to lock those procedures into a
pattern which would be difficult to integrate other operations into.
So, for SQL server, or any resource that supports transactions, I
would never write a stored procedure that has transaction management
code in it.
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in message
news:Op******** ******@TK2MSFTN GP09.phx.gbl... I do not believe we are discussing the same thing. I am strictly
speaking about SQL Server transactions and as you have indicated you
are talking about business layer "transactio ns." If the requirement
were passed to the DBA who was writing the stored procedure that
File IO needs to take place, he should kick it back and say that is
outside the scope of the sql server transaction.
SQL Server transactions are strictly for maintaining data integrity
and consistency, not to mention they give you a named place to
restore to instead of a datetime stamp. I believe you would benefit
from not one, but both, i.e., the data integrity transaction and the
process integrity transaction.
Eric
Nicholas Paldino [.NET/C# MVP] wrote: Eric,
I would agree with you, transactions should not exist in the
front end (nor should dynamic SQL statements).
I am referring to the business layer. It is at this level that
the transactions should be controlled, and not by the programmer,
but rather, through the administrative tool (which gets the initial
values from attributes declared on the class).
The reason for this is that it allows for easy extenisibility in
the future. For example, say you have your transaction code in your
stored procedure now. Say that you have some piece of code that
calls the stored procedure. Later on, you have a requirement to
write to a file when the procedure completes, and to not write to
the file when it fails. You would want some sort of transaction
manager to coordinate this. Of course, this assumes that the file
system is transactional (which it is in Longhorn).
The point is that when you start performing transaction
management in the resource that is being handled by the transacton,
you severely limit the other business processes that the resource
can be included in. The file is a simple case, but what about
message queues? What about both queues and emails? As you add
more resources to the transaction state (outside of the database),
you need a way to abort them all.
It is because of the fact that I am going to make my business
process transactional, and not just my database operations
transactional that I use something like Enterprise Services, or the
new Transaction model being introduced in .NET 2.0. I believe that
the mindset of the db being the only transactional resource is on
the way of being well behind us, and that external entities are
needed to control all of these resources, should something fail
while trying to perform operations on them.
"Eric Sabine" <mopar41@mail_a fter_hot_not_be fore.com> wrote in
message news:%2******** *******@TK2MSFT NGP14.phx.gbl.. .
Are you talking about database transactions or something else?
Database transactions, i.e, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN,
really should not be used in the front-end application. You
greatly increase your risk to locking, blocking, inconsistent
data, corrupt data, long running transactions (which leads back to
locking and blocking), uncommitted transactions, and more. Transactions
should be kept as short as possible to keep database access clean. I
take
the totally opposite stance and say transactions and typed sql
statements (even though you didn't mention these but they would go
hand-in-hand with someone who was creating transactions in the FE)
should never exist in the front-end. I believe that the only
access from a front-end should be limited to executing stored
procedures. Eric
Nicholas Paldino [.NET/C# MVP] wrote:
> Mike,
>
> Personally, I think that managing transaction state in your
> stored procedures is a very, very bad idea. It limits how they
> can be used elsewhere, and for the most part, are harder to
> maintain (as you have more and more sp's calling each other,
> trying to maintain transaction state is a pain).
>
> I would recommend using EnterpriseServi ces for handling
> transaction state. There are a number of reasons for this, the
> best one being easy maintainability (you can turn transactions on
> and off with the flick of a switch, or change their behavior).
> Another reason to handle this would be because it offers the
> easiest translation path to Indigo.
> Hope this helps.
>
>
> "Mike P" <mr*@telcoelect ronics.co.uk> wrote in message
> news:e4******** ******@TK2MSFTN GP14.phx.gbl...
>> I've been using C# transactions for a while and had no problems
>> with them. Using try catch blocks I can trap basically all
>> possible errors and rollback all necessary data.
>>
>> Over the last few days I've been trying to convert some of this
>> code to SQL Server stored procedures, but it seems to lack many
>> of the benefits of C# transactions - a lot of the errors don't
>> seem to be trapped by the SQL error trapping (e.g. if I do an update
>> on a row that doesn't exist, no rollback occurs and execution
>> continues, if a table I am trying to access doesn't exist then
>> the sproc crashes). Can anybody tell me what reasons there are
>> for writing your
>> transactions in stored procedures rather than your .NET code, as
>> there don't seem to be any to me.
>>
>>
>> Any assistance would be really appreciated.
>>
>>
>> Cheers,
>>
>> Mike
>>
>>
>> *** Sent via Developersdex http://www.developersdex.com ***
>> Don't just participate in USENET...get rewarded for it! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Christopher J. Bottaro |
last post by:
Hi,
Why is there no support for explicit transactions in the DB API? I mean
like transaction() to start the trans and commit() and rollback() would end
the trans or something.
The reason why I ask is because I wrote a daemon that interacts with a
Postgres DB. The value of CURRENT_TIMESTAMP according to Postgres is NOT
the actual...
|
by: Richard Maher |
last post by:
Hi,
I am seeking the help of volunteers to test some software that I've
developed which facilitates distributed two-phase commit transactions,
encompassing any resource manager (e.g. SQL/Server or Oracle) controlled by
Microsoft's Distributed Transaction Coordinator in a Windows2000
environment, with any resource manager under the control...
|
by: Iain Mcleod |
last post by:
I wish to do a series of inserts on a sql server database in the context of
a transaction. The inserts will be done as a series of stored procedure
calls. I wish to be able to rollback any inserts should one fail.
A quick google on ".net transactions" and the following page comes up:...
|
by: Terri |
last post by:
I have a table called Transactions with 3 fields: ID, Date, and Amount. Each
ID can have multiple transactions in one particular year. An ID might not
have had any transactions in recent years.
For each ID I would like to sum all the transactions for the most recent
year in which one or more transactions have occurred.
Thanks for any help...
|
by: TD |
last post by:
I am trying to add transactions to my code. The original code worked
fine until I followed an example to setup transactions, now the code
does strange things, but no error messages.
Could someone please review my before and after code and tell me the
proper way to add transactions to my code?
Thanks,
TD
| | |
by: mark |
last post by:
In Java, you can use JBoss or similar to host EJB that will manage your
transactions for you. You could, of course, write your own transactions
using JDBC.
In .NET, we can specify our own transactions using ADO.NET. Is there a
compatible tool within .NET to JBoss, where the transactions are managed for
you?
Thanks in advance.
Mark
|
by: radcaesar |
last post by:
Customer Table
ID Name Address City Phone
1 Vijay Stores 6,Gandhi Road Pondy 0413-276564
2 Ram Stores 3, MG Road, Pondicherry 0413-29543756
3 Balu Papers 3, RG St, Neyveli +919366228639
4 Senthil Papers 3, JN Road Cuddalore 04142-287654
6 TEst PRT PRT 246246
7 xxxx ggg eryyty drggd
|
by: Sridhar |
last post by:
Hi,
I am trying to implement sql transactions. But I am not knowing how to
do that. I created a data access layer which contains methods to
select/insert/update tables in a database. I have also created a business
logic layer to retrieve/update the data from the data access layer. All of
this is working fine if there are no transactions...
|
by: Rami |
last post by:
I have some requirement for an automated payment system. The system has
four machines setup as follows:
1- Two machines have a clustered database.
2- Two machines have a .net business logic component that will handle
payment transactions with certain external component (Payment Gateway)
My query is regarding transaction handling inside...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...
| |
