error handling and transactions

error handling and transactions - speed question

microsoft.public.sqlserver.programming

23 Mar 2006 10:09 PM

Keith G Hicks

I've been very carefully studying
http://www.sommarskog.se/error-handling-II.html recently. I went through it
some time ago before I was very familiar with working in SQL and it was all
sort of mysterious to me. Now I'm finding it to be very helpful.

Here's my issue right now: I have a former coworker who has been wroking in
sql 2k for several years now (we tend to disagree often on programming
techniques). When I asked him today how extensively he implements the sorts
of strategies detailed in Erland's articles he said that he rarely does any
of this. I was surprised. He said that occasionally and with great restraint
he'll use a begin/commit structure. He says that if you have a system with
many users then you have to worry about the system getting bogged down in
transactions. I mentioned the classic example of transferring money from a
savings account to a checking acount and what if something fails between the
2 update statements and he said that if you have a banking system where
thousands of people are hammering away at the system all day long then using
transactiosn in such a situation would be detrimental to performance. He
thinks that in theory using begin/commmit and @@error is very good but in
it's not very practical in the real world. I'm thinking that would be true
if you didn't design your error handling carefully as Erland outlines. I
would very much appreciate some feedback from the experts on this topic
because in my opinion, not handling errors at all is a bad idea. Is my
friend way off, somewhere in the middle or right on target?

Thanks,

Keith

24 Mar 2006 9:52 AM

Tibor Karaszi

Let me guess, he's the type of guy who takes a chance when bicycling into a crossing, and don't
break in order to not loose speed; hoping that no car will intersect?

Sure, if your customer (MD, president, or whatever) agrees that some crap in the database is OK, you
don't have to worry (as much) about transaction handling. But make sure it is a conscious decision,
taken higher up in the organization and make sure you have this in writing (or it will be your ass).

Another way of looking at a DBMS is as a state machine. Each modification takes you from one state
to another state. With transactions, you can protect yourself from disallowed states.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/

Show quote

"Keith G Hicks" <k**@comcast.net> wrote in message news:ugsl8asTGHA.1576@tk2msftngp13.phx.gbl...
> I've been very carefully studying
> http://www.sommarskog.se/error-handling-II.html recently. I went through it
> some time ago before I was very familiar with working in SQL and it was all
> sort of mysterious to me. Now I'm finding it to be very helpful.
>
> Here's my issue right now: I have a former coworker who has been wroking in
> sql 2k for several years now (we tend to disagree often on programming
> techniques). When I asked him today how extensively he implements the sorts
> of strategies detailed in Erland's articles he said that he rarely does any
> of this. I was surprised. He said that occasionally and with great restraint
> he'll use a begin/commit structure. He says that if you have a system with
> many users then you have to worry about the system getting bogged down in
> transactions. I mentioned the classic example of transferring money from a
> savings account to a checking acount and what if something fails between the
> 2 update statements and he said that if you have a banking system where
> thousands of people are hammering away at the system all day long then using
> transactiosn in such a situation would be detrimental to performance. He
> thinks that in theory using begin/commmit and @@error is very good but in
> it's not very practical in the real world. I'm thinking that would be true
> if you didn't design your error handling carefully as Erland outlines. I
> would very much appreciate some feedback from the experts on this topic
> because in my opinion, not handling errors at all is a bad idea. Is my
> friend way off, somewhere in the middle or right on target?
>
> Thanks,
>
> Keith
>
>

24 Mar 2006 9:53 AM

Rogas69

geee. and he's a db programmer?
if he doesn't use begin/commit statments in multi statement stored procs he
eventually ends up with much bigger number of transactions than with these
statements. each statement is auto committed by default, unless he uses
"implicit transactions on" setting..
http://msdn2.microsoft.com/en-us/library/ms175523.aspx

Peter

24 Mar 2006 1:21 PM

Wayne Snyder

I completely agree with Tibor... and have NEVER written any serious
application without doing proper error handling... If the data is not
important - that's one thing... but if it is used to run your business, then
you have an obligation to make sure things are good...Yes, depending on the
work you are doing, transactions might cause some locking - that is the
INTENDED way they work... They prevent one persons work from overwriting and
interfering with another..

To presumptively say that trans cause to many problems is disappointing and
lazy.

--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC

I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.

Show quote

"unknown" wrote:

>

24 Mar 2006 11:23 PM

Paul Nielsen (MVP)

"Slow and right" beats "fast and wrong" two out of three times...
because there's always someone who doesn't care about the right answer, just
give me any answer fast.

I, for one, strongly agree with the other comments here, that good logical
transactional control and error handling is far more important than shaving
off a few milliseconds at the risk of a wrong answer.

btw, when I've dealt with folks who didn't see much value in certain SQL
technologies it was because they didn't really understand the technology -
like the data modeler who said that query path to the data didn't matter in
a database design, and sure enough, he couldn't write a basic query.

-Paul Nielsen
SQL Server MVP

Show quote

"Keith G Hicks" <k**@comcast.net> wrote in message
news:ugsl8asTGHA.1576@tk2msftngp13.phx.gbl...
> I've been very carefully studying
> http://www.sommarskog.se/error-handling-II.html recently. I went through
> it
> some time ago before I was very familiar with working in SQL and it was
> all
> sort of mysterious to me. Now I'm finding it to be very helpful.
>
> Here's my issue right now: I have a former coworker who has been wroking
> in
> sql 2k for several years now (we tend to disagree often on programming
> techniques). When I asked him today how extensively he implements the
> sorts
> of strategies detailed in Erland's articles he said that he rarely does
> any
> of this. I was surprised. He said that occasionally and with great
> restraint
> he'll use a begin/commit structure. He says that if you have a system with
> many users then you have to worry about the system getting bogged down in
> transactions. I mentioned the classic example of transferring money from a
> savings account to a checking acount and what if something fails between
> the
> 2 update statements and he said that if you have a banking system where
> thousands of people are hammering away at the system all day long then
> using
> transactiosn in such a situation would be detrimental to performance. He
> thinks that in theory using begin/commmit and @@error is very good but in
> it's not very practical in the real world. I'm thinking that would be true
> if you didn't design your error handling carefully as Erland outlines. I
> would very much appreciate some feedback from the experts on this topic
> because in my opinion, not handling errors at all is a bad idea. Is my
> friend way off, somewhere in the middle or right on target?
>
> Thanks,
>
> Keith
>
>