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 |
|
lionofdezert
Aged Yak Warrior
885 Posts |
 Posted - 2008-06-27 : 07:29:04
|
| When few end users are updating continuously to same table, WHY I AM FACING TIMEOUT MESSAGE while querying select statement on same table, when table is being updated.What should i do ? |
|
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2008-06-27 : 08:31:06
|
| simple question but big answer :)you should read about (and understand) isolation levels as it pertains to concurrency.Basically you need to minimize the time (and number of rows) that locks occur on the table when updating. If you don't mind "dirty reads" you can perform your SELECT with a transaction isolation level of "read uncommitted".Are the end-user updates happening via Stored procedure calls on just one row at a time? Or is there some application that is "opening" a table and holding locks on it throughout the time they are changing values?Be One with the OptimizerTG |
 |
|
|
maninder
Posting Yak Master
100 Posts |
Posted - 2008-06-27 : 15:14:17
|
| Which SQL version/Edition.Are you on latest Service PAcks.What ISOLATION levels are you using..(Even the Client side matters)While running a select statement use select .... from tablename with (NOLOCK)Maninder |
|
|
|
Van
Constraint Violating Yak Guru
462 Posts |
Posted - 2008-06-27 : 15:31:54
|
| Keep in mind that NOLOCK will cause dirty reads... |
|
|
|
maninder
Posting Yak Master
100 Posts |
Posted - 2008-06-27 : 16:32:33
|
| Yes thats true, but if you are not affected by the LATEST Result in your Query/Report... you should use it.. again, do not use this extensively. Just as REQUIRED.Maninder |
|
|
|
|
|
|
Record locking