Deafult NULL not working

I am using SQL Server 2000. I have a Column with DataType int and default value specified as (null). But, With Insert or Update if the column value is Blank, 0 is getting inserted instead of the desired NULL.

Thanks

Is there, by chance, a trigger on this table?|||

NO. There is no trigger on this Table.

|||Well... create a complete DDL script for this table and post it here - something must be there.

Also, how you make a insert / update - directly or via some kind of stored proc? There may be a preprocessing in there that you miss, for example.|||

What exactly do you mean by "column value is blank". If you are explicitly trying to force a blank into the field then yes, it is going to get assigned as zero:

create table dbo.testo
( rid int,
x int default (null)
)

insert into dbo.testo select 1, ' '

insert into dbo.testo (rid) select 1

select * from dbo.testo

/*
rid x
-- --
1 0
1 NULL
*/

If, however, you are wanting to insert a row and allow the default to occur you must do something similar to what I hilighted in red

If you want to UPDATE to the default value, you can use syntax something like this:

update dbo.testO
set x=default
where rid =1

|||

YES. The Column Value is getting evaluated to '' as the user did not enter anything for the field on the form. Is there any way '' can be evaluated to NULL instead of 0.

- vmrao

|||declare @.p1 varchar(255)

set @.p1 = ''

insert into Mytable (rid, myintcol)
select 10, nullif(@.p1, '')
|||Thanks. NULLIF worked.

Deafult data for Image field

Hi,

I am storing my upoaded images in sql server. However, if the user does not upload an image, a broken link is shown in the page.
All that shows up in the DB field is <Binary>.

Can we set this field to a default value?
Is it possible to view this binary data.

I would like a default blank gif to be returned if no image is uploaded.

Regards,
JBISNULL(yourField, @.Default) ? I rarely use the image field, so i'm not sure if this works.|||What if an image is removed at a later date? What would you like to display then?

My gut feeling is that it would be best to not handle this through the database, but through one of your business objects.

With the database, you can make use of the ISNULL, but you cannot use an image data type for a local variable, so KraGiE's suggestion won't work as written. I was messing around with the NorthWind database and came up with this sort of thing:

-- this is for testing, should have a default photo sitting in a table somewhere and that table should be used instead of the @.myTest table
DECLARE @.myTest table (DefaultPhoto image)
INSERT INTO @.myTest SELECT photo from employees WHERE employeeID = 1
SELECT
photo,
DefaultPhoto,
ISNULL(photo,DefaultPhoto) AS DisplayPhoto
FROM
employees
LEFT OUTER JOIN
@.myTest ON employees.photo IS NULL

I'm sure there are 100 better ways to do this :-)

Terri|||ISNULL(Photo, SELECT Photo From Employees Where EmployeeID = @.DefaultPhotoID)

:)

Deadlocks?

hey can i get idea about deadlocks?
how to avoide deadlock actually?
what are the different stretegies used for this technique?> Continue with latest book by Kalen Delaney.
Which one is this Dejan? Are you refering to "Inside SQL Server" ?
--
HTH,
Vinod Kumar
MCSE, DBA, MCAD
http://www.extremeexperts.com
"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
message news:ugi5BmVbDHA.2632@.TK2MSFTNGP09.phx.gbl...
> Start with Books OnLine, searc for deadlock, there are quite a few topics.
> Continue with latest book by Kalen Delaney.
> --
> Dejan Sarka, SQL Server MVP
> FAQ from Neil & others at: http://www.sqlserverfaq.com
> Please reply only to the newsgroups.
> PASS - the definitive, global community
> for SQL Server professionals - http://www.sqlpass.org
> "hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
> news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> > hey can i get idea about deadlocks?
> > how to avoide deadlock actually?
> > what are the different stretegies used for this technique?
>|||Kim's book was very good on locking in general, but pretty sparse when it
came to dealing with deadlocks.
Just my opinion.
Bob Castleman
SuccessWare Software
"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
message news:ugi5BmVbDHA.2632@.TK2MSFTNGP09.phx.gbl...
> Start with Books OnLine, searc for deadlock, there are quite a few topics.
> Continue with latest book by Kalen Delaney.
> --
> Dejan Sarka, SQL Server MVP
> FAQ from Neil & others at: http://www.sqlserverfaq.com
> Please reply only to the newsgroups.
> PASS - the definitive, global community
> for SQL Server professionals - http://www.sqlpass.org
> "hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
> news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> > hey can i get idea about deadlocks?
> > how to avoide deadlock actually?
> > what are the different stretegies used for this technique?
>|||I should be more precise. It is "Hands-On SQL Server 2000 : Troubleshooting
Locking and Blocking" ebook, available at
http://www.shareit.com/product.html?cart=1&productid=183645&affiliateid=&languageid=1&cookies=1&backlink=http://www.netimpress.com/Default.asp?¤cies=USD.
--
Dejan Sarka, SQL Server MVP
FAQ from Neil & others at: http://www.sqlserverfaq.com
Please reply only to the newsgroups.
PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Vinodk" <vinodk_sct@.hotmail.com> wrote in message
news:OKWfVIWbDHA.3768@.tk2msftngp13.phx.gbl...
> > Continue with latest book by Kalen Delaney.
> Which one is this Dejan? Are you refering to "Inside SQL Server" ?
> --
> HTH,
> Vinod Kumar
> MCSE, DBA, MCAD
> http://www.extremeexperts.com
>
> "Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
> message news:ugi5BmVbDHA.2632@.TK2MSFTNGP09.phx.gbl...
> > Start with Books OnLine, searc for deadlock, there are quite a few
topics.
> > Continue with latest book by Kalen Delaney.
> >
> > --
> > Dejan Sarka, SQL Server MVP
> > FAQ from Neil & others at: http://www.sqlserverfaq.com
> > Please reply only to the newsgroups.
> > PASS - the definitive, global community
> > for SQL Server professionals - http://www.sqlpass.org
> >
> > "hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
> > news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> > > hey can i get idea about deadlocks?
> > > how to avoide deadlock actually?
> > > what are the different stretegies used for this technique?
> >
> >
>|||Vinod,
I guess Dejan is referring to..
Hands-On SQL Server 2000 : Troubleshooting Locking and Blocking (ebook)
By Kalen Delaney
http://www.shareit.com/product.html?cart=1&productid=183645&affiliateid=&languageid=1&cookies=1&backlink=http://www.netimpress.com/Default.asp?¤cies=USD
--
Dinesh.
SQL Server FAQ at
http://www.tkdinesh.com
"Vinodk" <vinodk_sct@.hotmail.com> wrote in message
news:OKWfVIWbDHA.3768@.tk2msftngp13.phx.gbl...
> > Continue with latest book by Kalen Delaney.
> Which one is this Dejan? Are you refering to "Inside SQL Server" ?
> --
> HTH,
> Vinod Kumar
> MCSE, DBA, MCAD
> http://www.extremeexperts.com
>
> "Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
> message news:ugi5BmVbDHA.2632@.TK2MSFTNGP09.phx.gbl...
> > Start with Books OnLine, searc for deadlock, there are quite a few
topics.
> > Continue with latest book by Kalen Delaney.
> >
> > --
> > Dejan Sarka, SQL Server MVP
> > FAQ from Neil & others at: http://www.sqlserverfaq.com
> > Please reply only to the newsgroups.
> > PASS - the definitive, global community
> > for SQL Server professionals - http://www.sqlpass.org
> >
> > "hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
> > news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> > > hey can i get idea about deadlocks?
> > > how to avoide deadlock actually?
> > > what are the different stretegies used for this technique?
> >
> >
>|||First of all I haven't read everything, for example I haven't read the last
book of Kalen.
But most documentation I have seen describe deadlocks which can be expected,
I haven't seen (or missed them) descriptions of deadlocks that are totally
unexpected.
We had a deadlock between one transaction and a single select statement not
run in a transaction. The statement selected only one row of one table, but
still deadlocked with the transaction. From a select you can not see which
locks are used during the transaction, because it is so fast. Trapping the
deadlock and seeing which locks where used was difficult because when the
deadlock is detected by sql-server the information (read locks) disappears.
Because we did not suspect the 'select' to cause any problems it
took a long time before we could determine the cause of the deadlock
and solve the problem. (The deadlock was difficult to produce to begin
with).
In the end, with the database we had then, I could recreate the deadlock at
will within the QA. Outside that database even with the same data I could
not recreate the problem.
So do not exclude simple select statements when hunting down the culprits of
deadlocks.
Ben Brugman
"hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> hey can i get idea about deadlocks?
> how to avoide deadlock actually?
> what are the different stretegies used for this technique?|||Thankx Dinesh and Dejan ... Looks an good book to have ...
--
HTH,
Vinod Kumar
MCSE, DBA, MCAD
http://www.extremeexperts.com
"Dinesh.T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
news:eBLD0fWbDHA.2960@.tk2msftngp13.phx.gbl...
> Vinod,
> I guess Dejan is referring to..
> Hands-On SQL Server 2000 : Troubleshooting Locking and Blocking (ebook)
> By Kalen Delaney
>
http://www.shareit.com/product.html?cart=1&productid=183645&affiliateid=&languageid=1&cookies=1&backlink=http://www.netimpress.com/Default.asp?¤cies=USD
> --
> Dinesh.
> SQL Server FAQ at
> http://www.tkdinesh.com
> "Vinodk" <vinodk_sct@.hotmail.com> wrote in message
> news:OKWfVIWbDHA.3768@.tk2msftngp13.phx.gbl...
> > > Continue with latest book by Kalen Delaney.
> >
> > Which one is this Dejan? Are you refering to "Inside SQL Server" ?
> >
> > --
> > HTH,
> > Vinod Kumar
> > MCSE, DBA, MCAD
> > http://www.extremeexperts.com
> >
> >
> > "Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote
in
> > message news:ugi5BmVbDHA.2632@.TK2MSFTNGP09.phx.gbl...
> > > Start with Books OnLine, searc for deadlock, there are quite a few
> topics.
> > > Continue with latest book by Kalen Delaney.
> > >
> > > --
> > > Dejan Sarka, SQL Server MVP
> > > FAQ from Neil & others at: http://www.sqlserverfaq.com
> > > Please reply only to the newsgroups.
> > > PASS - the definitive, global community
> > > for SQL Server professionals - http://www.sqlpass.org
> > >
> > > "hrishikesh musale" <musaleh@.mahindrabt.com> wrote in message
> > > news:0a5c01c36d58$8a43e1c0$a501280a@.phx.gbl...
> > > > hey can i get idea about deadlocks?
> > > > how to avoide deadlock actually?
> > > > what are the different stretegies used for this technique?
> > >
> > >
> >
> >
>sql

Deadlocks....What is going on?

We have background processes that constantly insert into and update
table A. When we do selects from table A from our end user
application (we have many selects that hit this table), we quite
frequently get deadlocks. Is it not safe to select from a table that
is being updated? Surely we do not have to put (updlock) hint on
all of our queries... Is thier not some way to control this from the
update/insert routines (as opposed to chaning all of our selects)
TIA
A few tips that may help:
On your INSERT and UPDATE routines do the following:
1. Make the transactions as fast as possible. For example, do your data
scrubbing and cleaning and error checking first, then issue the transaction
portion.
2. Use the tables and views in the same order (if possible) within those
routines. This will make other parts of your application wait to acquire
locks and should lessen the deadlocks.
3. If you know that your update is going to affect a significant portion of
the table, you may wish to consider a table lock hint in the query itself.
This would keep your SELECTs from even beginning to view the table while it
was under a large and lengthy update.
If you don't mind your SELECTS looking at data that is under modification,
you may wish to set your ANSI Transaction Isolation Level to READ
UNCOMMITTED. This will allow for dirty reads and so forth. You wouldn't
have to modify all of your SELECT queries, just SET your session for READ
UNCOMMITTED.
HTH
Rick Sawtell
MCT, MCSD, MCDBA
"Tommy" <talfano@.ncpsolutions.com> wrote in message
news:86ecf3f7.0410051431.54114c50@.posting.google.c om...
> We have background processes that constantly insert into and update
> table A. When we do selects from table A from our end user
> application (we have many selects that hit this table), we quite
> frequently get deadlocks. Is it not safe to select from a table that
> is being updated? Surely we do not have to put (updlock) hint on
> all of our queries... Is thier not some way to control this from the
> update/insert routines (as opposed to chaning all of our selects)
> TIA
|||your update uses not the same index on the table as the
select does. so you access data in different directions
which could cause a deadlock.
two choices:
- either put a NOLOCk hint on the select
- use the same index for the where-clause on the select &
update

>--Original Message--
>A few tips that may help:
>On your INSERT and UPDATE routines do the following:
>1. Make the transactions as fast as possible. For
example, do your data
>scrubbing and cleaning and error checking first, then
issue the transaction
>portion.
>2. Use the tables and views in the same order (if
possible) within those
>routines. This will make other parts of your application
wait to acquire
>locks and should lessen the deadlocks.
>3. If you know that your update is going to affect a
significant portion of
>the table, you may wish to consider a table lock hint in
the query itself.
>This would keep your SELECTs from even beginning to view
the table while it
>was under a large and lengthy update.
>If you don't mind your SELECTS looking at data that is
under modification,
>you may wish to set your ANSI Transaction Isolation Level
to READ
>UNCOMMITTED. This will allow for dirty reads and so
forth. You wouldn't
>have to modify all of your SELECT queries, just SET your
session for READ[vbcol=seagreen]
>UNCOMMITTED.
>
>HTH
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>
>"Tommy" <talfano@.ncpsolutions.com> wrote in message
>news:86ecf3f7.0410051431.54114c50@.posting.google. com...
into and update[vbcol=seagreen]
user[vbcol=seagreen]
we quite[vbcol=seagreen]
from a table that[vbcol=seagreen]
(updlock) hint on[vbcol=seagreen]
this from the[vbcol=seagreen]
our selects)
>
>.
>
|||Rick,
Thanks for your suggestions. We are trying these out right now. I
don't think locking the entire table is an option, but can try dirty
reads, as the transactions should not take that long to complete.
Thanks again,
Tommy
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message news:<#lVO4KzqEHA.3840@.TK2MSFTNGP10.phx.gbl>...[vbcol=seagreen]
> A few tips that may help:
> On your INSERT and UPDATE routines do the following:
> 1. Make the transactions as fast as possible. For example, do your data
> scrubbing and cleaning and error checking first, then issue the transaction
> portion.
> 2. Use the tables and views in the same order (if possible) within those
> routines. This will make other parts of your application wait to acquire
> locks and should lessen the deadlocks.
> 3. If you know that your update is going to affect a significant portion of
> the table, you may wish to consider a table lock hint in the query itself.
> This would keep your SELECTs from even beginning to view the table while it
> was under a large and lengthy update.
> If you don't mind your SELECTS looking at data that is under modification,
> you may wish to set your ANSI Transaction Isolation Level to READ
> UNCOMMITTED. This will allow for dirty reads and so forth. You wouldn't
> have to modify all of your SELECT queries, just SET your session for READ
> UNCOMMITTED.
>
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
> "Tommy" <talfano@.ncpsolutions.com> wrote in message
> news:86ecf3f7.0410051431.54114c50@.posting.google.c om...

Deadlocks....What is going on?

We have background processes that constantly insert into and update
table A. When we do selects from table A from our end user
application (we have many selects that hit this table), we quite
frequently get deadlocks. Is it not safe to select from a table that
is being updated? Surely we do not have to put (updlock) hint on
all of our queries... Is thier not some way to control this from the
update/insert routines (as opposed to chaning all of our selects)
TIAA few tips that may help:
On your INSERT and UPDATE routines do the following:
1. Make the transactions as fast as possible. For example, do your data
scrubbing and cleaning and error checking first, then issue the transaction
portion.
2. Use the tables and views in the same order (if possible) within those
routines. This will make other parts of your application wait to acquire
locks and should lessen the deadlocks.
3. If you know that your update is going to affect a significant portion of
the table, you may wish to consider a table lock hint in the query itself.
This would keep your SELECTs from even beginning to view the table while it
was under a large and lengthy update.
If you don't mind your SELECTS looking at data that is under modification,
you may wish to set your ANSI Transaction Isolation Level to READ
UNCOMMITTED. This will allow for dirty reads and so forth. You wouldn't
have to modify all of your SELECT queries, just SET your session for READ
UNCOMMITTED.
HTH
Rick Sawtell
MCT, MCSD, MCDBA
"Tommy" <talfano@.ncpsolutions.com> wrote in message
news:86ecf3f7.0410051431.54114c50@.posting.google.com...
> We have background processes that constantly insert into and update
> table A. When we do selects from table A from our end user
> application (we have many selects that hit this table), we quite
> frequently get deadlocks. Is it not safe to select from a table that
> is being updated? Surely we do not have to put (updlock) hint on
> all of our queries... Is thier not some way to control this from the
> update/insert routines (as opposed to chaning all of our selects)
> TIA|||your update uses not the same index on the table as the
select does. so you access data in different directions
which could cause a deadlock.
two choices:
- either put a NOLOCk hint on the select
- use the same index for the where-clause on the select &
update
>--Original Message--
>A few tips that may help:
>On your INSERT and UPDATE routines do the following:
>1. Make the transactions as fast as possible. For
example, do your data
>scrubbing and cleaning and error checking first, then
issue the transaction
>portion.
>2. Use the tables and views in the same order (if
possible) within those
>routines. This will make other parts of your application
wait to acquire
>locks and should lessen the deadlocks.
>3. If you know that your update is going to affect a
significant portion of
>the table, you may wish to consider a table lock hint in
the query itself.
>This would keep your SELECTs from even beginning to view
the table while it
>was under a large and lengthy update.
>If you don't mind your SELECTS looking at data that is
under modification,
>you may wish to set your ANSI Transaction Isolation Level
to READ
>UNCOMMITTED. This will allow for dirty reads and so
forth. You wouldn't
>have to modify all of your SELECT queries, just SET your
session for READ
>UNCOMMITTED.
>
>HTH
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>
>"Tommy" <talfano@.ncpsolutions.com> wrote in message
>news:86ecf3f7.0410051431.54114c50@.posting.google.com...
>> We have background processes that constantly insert
into and update
>> table A. When we do selects from table A from our end
user
>> application (we have many selects that hit this table),
we quite
>> frequently get deadlocks. Is it not safe to select
from a table that
>> is being updated? Surely we do not have to put
(updlock) hint on
>> all of our queries... Is thier not some way to control
this from the
>> update/insert routines (as opposed to chaning all of
our selects)
>> TIA
>
>.
>|||Rick,
Thanks for your suggestions. We are trying these out right now. I
don't think locking the entire table is an option, but can try dirty
reads, as the transactions should not take that long to complete.
Thanks again,
Tommy
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message news:<#lVO4KzqEHA.3840@.TK2MSFTNGP10.phx.gbl>...
> A few tips that may help:
> On your INSERT and UPDATE routines do the following:
> 1. Make the transactions as fast as possible. For example, do your data
> scrubbing and cleaning and error checking first, then issue the transaction
> portion.
> 2. Use the tables and views in the same order (if possible) within those
> routines. This will make other parts of your application wait to acquire
> locks and should lessen the deadlocks.
> 3. If you know that your update is going to affect a significant portion of
> the table, you may wish to consider a table lock hint in the query itself.
> This would keep your SELECTs from even beginning to view the table while it
> was under a large and lengthy update.
> If you don't mind your SELECTS looking at data that is under modification,
> you may wish to set your ANSI Transaction Isolation Level to READ
> UNCOMMITTED. This will allow for dirty reads and so forth. You wouldn't
> have to modify all of your SELECT queries, just SET your session for READ
> UNCOMMITTED.
>
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
> "Tommy" <talfano@.ncpsolutions.com> wrote in message
> news:86ecf3f7.0410051431.54114c50@.posting.google.com...
> > We have background processes that constantly insert into and update
> > table A. When we do selects from table A from our end user
> > application (we have many selects that hit this table), we quite
> > frequently get deadlocks. Is it not safe to select from a table that
> > is being updated? Surely we do not have to put (updlock) hint on
> > all of our queries... Is thier not some way to control this from the
> > update/insert routines (as opposed to chaning all of our selects)
> >
> > TIA

Deadlocks, why?

We have a problem with a table giving us deadlock issues and we can't
figure out why.

It's a table we write to fairly often perhaps 50 times a minute. And
also do a select of 200 rows at a time from 4 servers every 5 minutes or so.

We are only keeping 48 hours worth of rows in the table which averages
at 30000 a day on a busy day.

This table has 1 PK and 2 FKs plus one TEXT column which does not
participate in the WHERE clause.

We are using binded variables.

We have applied the latest patch to SQL2003 server running on
Windows2003. The patch is supposed to resolve deadlock issues.

Anyone have any advice on how to alleviate this problem.

ThanksDon Vaillancourt (donv@.webimpact.com) writes:
> We have a problem with a table giving us deadlock issues and we can't
> figure out why.
> It's a table we write to fairly often perhaps 50 times a minute. And
> also do a select of 200 rows at a time from 4 servers every 5 minutes or
> so.
> We are only keeping 48 hours worth of rows in the table which averages
> at 30000 a day on a busy day.
> This table has 1 PK and 2 FKs plus one TEXT column which does not
> participate in the WHERE clause.
> We are using binded variables.
> We have applied the latest patch to SQL2003 server running on
> Windows2003. The patch is supposed to resolve deadlock issues.
> Anyone have any advice on how to alleviate this problem.

I'm afraid that there is not enough information your post to make it
possible to give solutions.

Except one: if it is acceptable that one of the process is always
is the victim, make this process emit SET DEADLOCK_PRIORITY LOW.
We have done this in quite a few places in our system. Background
processes don't scream so much about deadlocks as users do.

But if that is not an option, I can only suggest methods to get more
information.

First, have you enabled deadlock trace on your server and looked at
the output? To enable deadlock trace, use Enterprise Manager to add
these two startup options: -T 1204 -T 3605.

Once you have the deadlock output, try to narrow down exactly which
queries that collide. Once you have the queries, you could post them
together with the table definitions (including indexes!). Or you could
post the deadlock traces (which is not very easy to interpret).

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Oh, I know which queries are involved and which ones are usually the
victims.

But thanks for the trace idea.

We haven't been able to replicate the deadlock issue in-house ass of
yet, but I will certainly keep those options in mind and use them.

Thank you

Erland Sommarskog wrote:
> Don Vaillancourt (donv@.webimpact.com) writes:
>> We have a problem with a table giving us deadlock issues and we can't
>> figure out why.
>>
>> It's a table we write to fairly often perhaps 50 times a minute. And
>> also do a select of 200 rows at a time from 4 servers every 5 minutes or
>> so.
>>
>> We are only keeping 48 hours worth of rows in the table which averages
>> at 30000 a day on a busy day.
>>
>> This table has 1 PK and 2 FKs plus one TEXT column which does not
>> participate in the WHERE clause.
>>
>> We are using binded variables.
>>
>> We have applied the latest patch to SQL2003 server running on
>> Windows2003. The patch is supposed to resolve deadlock issues.
>>
>> Anyone have any advice on how to alleviate this problem.
> I'm afraid that there is not enough information your post to make it
> possible to give solutions.
> Except one: if it is acceptable that one of the process is always
> is the victim, make this process emit SET DEADLOCK_PRIORITY LOW.
> We have done this in quite a few places in our system. Background
> processes don't scream so much about deadlocks as users do.
> But if that is not an option, I can only suggest methods to get more
> information.
> First, have you enabled deadlock trace on your server and looked at
> the output? To enable deadlock trace, use Enterprise Manager to add
> these two startup options: -T 1204 -T 3605.
> Once you have the deadlock output, try to narrow down exactly which
> queries that collide. Once you have the queries, you could post them
> together with the table definitions (including indexes!). Or you could
> post the deadlock traces (which is not very easy to interpret).|||Don Vaillancourt (donv@.webimpact.com) writes:
> Oh, I know which queries are involved and which ones are usually the
> victims.

OK. With table definitions and indexes and the queries, it's possible
that we can spot some potential problems. Without them it's going to
be hard. :-)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Don Vaillancourt wrote:
> Oh, I know which queries are involved and which ones are usually the
> victims.
> But thanks for the trace idea.
> We haven't been able to replicate the deadlock issue in-house ass of
> yet, but I will certainly keep those options in mind and use them.

Oh - you meant -that- kind of deadlock. Try some dried plums <g>.|||Hi Don

It could be that you will never be able to replicate the deadlock if your
hardware/environment is exactly the same. If you have not run
sp_blocker_pss80 you may want to try it
http://support.microsoft.com/defaul...kb;en-us;271509

John

"Don Vaillancourt" <donv@.webimpact.com> wrote in message
news:bWVxf.9204$43.7861@.nnrp.ca.mci.com!nnrp1.uune t.ca...
> Oh, I know which queries are involved and which ones are usually the
> victims.
> But thanks for the trace idea.
> We haven't been able to replicate the deadlock issue in-house ass of yet,
> but I will certainly keep those options in mind and use them.
> Thank you
>
> Erland Sommarskog wrote:
>> Don Vaillancourt (donv@.webimpact.com) writes:
>>> We have a problem with a table giving us deadlock issues and we can't
>>> figure out why.
>>>
>>> It's a table we write to fairly often perhaps 50 times a minute. And
>>> also do a select of 200 rows at a time from 4 servers every 5 minutes or
>>> so.
>>> We are only keeping 48 hours worth of rows in the table which averages
>>> at 30000 a day on a busy day.
>>>
>>> This table has 1 PK and 2 FKs plus one TEXT column which does not
>>> participate in the WHERE clause.
>>>
>>> We are using binded variables.
>>>
>>> We have applied the latest patch to SQL2003 server running on
>>> Windows2003. The patch is supposed to resolve deadlock issues.
>>>
>>> Anyone have any advice on how to alleviate this problem.
>>
>> I'm afraid that there is not enough information your post to make it
>> possible to give solutions.
>>
>> Except one: if it is acceptable that one of the process is always
>> is the victim, make this process emit SET DEADLOCK_PRIORITY LOW.
>> We have done this in quite a few places in our system. Background
>> processes don't scream so much about deadlocks as users do.
>>
>> But if that is not an option, I can only suggest methods to get more
>> information.
>>
>> First, have you enabled deadlock trace on your server and looked at
>> the output? To enable deadlock trace, use Enterprise Manager to add
>> these two startup options: -T 1204 -T 3605.
>>
>> Once you have the deadlock output, try to narrow down exactly which
>> queries that collide. Once you have the queries, you could post them
>> together with the table definitions (including indexes!). Or you could
>> post the deadlock traces (which is not very easy to interpret).
>

Deadlocks, severity level, and HRESULT

I am coding a large VB project, using Win2k, SQL Server 2000 SP1,
COM+, and VB6SP5. We have been having some problems with transactions
not being rolled back when an error was raised, and we have traced it
to the following situation. I'm looking for strategies of error
handling for this situation.
Sometimes (most times?) when there is a deadlock, Err.Number (HRESULT)
is 80004005 (-2147467259), but SOMETIMES IT IS 0 (that is, no error).
So because my code was not told about the error, it kept on
processing, but the problem is, THE DTC TRANSACTION HAS BEEN ABORTED,
so all further updates are not in a transaction. Usually DTC wakes up
sooner or later, but by then it might be too late - I may have made
updates thinking I was in a transaction when I was not. These updates
cannot be rolled back, and my database is left in an inconsistent
state. (FYI, the error I get from DTC are 8509 in the profiler,
reflected as 3704 in VB, if it is detected during processing. If it
is not detected until the root object is exiting, I see 8004e002.)
In particular, so far we have seen only ONE section of code where it
sometimes returns 0. All other areas of the code so far have returned
80004005. Also, in the place that returns 0, it only SOMETIMES
returns 0. Other times, it returns 80004005. There does not seem to
be any rhyme or reason to when it returns 0 and when it returns
80004005 (not that I've discovered yet, though). In all cases, the
error information in the profiler trace either:
Error: 1205, Severity: 13, State: 8
or
Error: 1205, Severity: 13, State: 50
There doesn't seem to be any correlation between the state=8 or the
state=50 errors.
All the error handling samples in MSDN use the "on error goto" trick,
but obviously that doesn't work if Err.Number = 0. Is it safe to just
check cn.Errors? Would there ever be any "informational" or "warning"
errors in there that I really should just leave alone and not report
an error? Is Deadlock the only one that could return 0 that really
should be aborted?
Thanks for any strategies you might know about!
Christine Wolak -- Senior Programmer
www.axiom-corp.comkaligrrl@.yahoo.com (Christine) wrote in message news:<d6363ccb.0309120837.1fc9d3e2@.posting.google.com>...
> I am coding a large VB project, using Win2k, SQL Server 2000 SP1,
> COM+, and VB6SP5. We have been having some problems with transactions
> not being rolled back when an error was raised
Okay, we have the answer. SET NOCOUNT ON in your stored procedure.
Always. In any stored procedure that you will be calling from a
client. Here is a link to a KB article:
http://support.microsoft.com/?kbid=240882 . How it can be "by design"
that an error gets raised and is not reported back to the caller, I
don't know, but apparently Microsoft does not plan to address this
issue any time soon. This article also says "a SQL Server trace may
reveal excessive attentions and rollbacks". We saw NONE of that.
NOTHING excessive - only EXPECTED stuff.
In our particular case, we had a deadlock earlier in the process,
during a stored procedure call. But since we were not told about it
(via Err.Number), our code kept processing. We did not have really
"unexpected" problems, because the stored procedure was a "fastpath",
and if for any reason the fastpath cannot be taken, then the code
takes the long path. And the stored procedure return code of 0 just
happens to indicate that the long path was necessary. So the code
just merrily went along, continuing to process.
Which for some reason DTC/COM+/MTS/whatever, let it keep doing. But
it's no longer in a transaction, and any updates at this point are
COMMITTED. At some point later, DTC would wake up and say "hey,
you're not supposed to still be doing stuff!" At this point, we might
see 3704, or 8004d00a (-2147168246), or, if it got all the way to the
very end and is exiting the root object, 8004e002 (-2147164158).
We had several stored procedures that work similarly, and only one had
the problem, and even then not every single time. The difference
would be the amount of informational messages passed back to the
client (DONE_IN_PROC messages).
So just take it from me - always use SET NOCOUNT ON in all stored
procedures called from VB/C++ except for the specific parts of data
that you want returned to the caller, and realize that, if you don't,
you could at any point stop receiving errors from SQL Server.
Christine Wolak -- www.axiom-corp.com