Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-02-21 : 09:40:56
|
| roy writes "i am getting a deadlock error on a simple SELECT statement and do not understand how a select statement could be chosen as a Deadlock victim. This particular table being queried has high activity of INSERTS/UPDATES. But I didn't think a SELECT could cause a deadlock. Any ideas what I might be doing wrong. This is SQL Server 7.0Here is my SQL Statement (The table name is session):select * from sessionHere is the error message I get:Server: Msg 1205, Level 13, State 50, Line 1Your transaction (process ID #68) was deadlocked with another process and has been chosen as the deadlock victim. Rerun your transaction." |
|
|
andre
Constraint Violating Yak Guru
259 Posts |
Posted - 2002-02-21 : 10:00:52
|
| Are these INSERTS/UPDATES using transactions? If so, you'll want to minimize them. Also, what isolation level are you using? Is it the repeatable read? |
 |
|
|
izaltsman
A custom title
1139 Posts |
Posted - 2002-02-21 : 10:07:33
|
| It might be helpful to see which command the other process is running. You can use trace flag 1204 to capture that information.Edited by - izaltsman on 02/21/2002 10:07:53 |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2002-02-21 : 10:19:29
|
| It is fiarly unusual for a statement like that to cause a deadlock.It's more common (in fact likely) with agregates.I would guess that something is trying to escalate to a table lock while the select has a shared lock on the table but is being blocked on a page/row.==========================================Cursors are useful if you don't know sql.Beer is not cold and it isn't fizzy. |
|
|
|
|
|
|
deadlock