There's probably no problems at all. Deadlocks are a natural event in the life of a database. I wouldn't spend a lot of time trying to track down the players involved. You may never be able to do it.

There are some MSDN articles that are worth looking at. Try starting here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_servdatabse_5xrn.asp

This link discusses a Trace flag that captures some debuging information about the threads involved in the deadlock and the resources that are locked.

In the meantime, it has always been my opinion that an application should not error out due to a deadlock. Catch the error and resubmit the query. The other connections will probably have completed their work and released their locks.

-Mike

>>I wouldn't expect a deadlock on two or more SELECT queries.
>>
>>>What would cause Deadlock errors while you're doing queries? I'd understand the larger potential for deadlocks during UPDATEs, but not for SELECTs.
>
>We're getting deadlock errors at peak times during the day on SELECTs. There are also concurrent UPDATEs and INSERTs going on, but we may have reached some limit. Any tips, pointers, adjustments, reading material you can point me to on tuning for this? We don't appear to be processor bound, but me may have a memory problem. (Dual 650's 1.5GB ram, about 250 users) TIA