nolock

I have two stored procedures running in separate threads, running on SQL Server 2005. One procedure inserts new rows into a set of tables and the other procedure deletes old data from the same set of tables. These procedures are running into a deadlock on the tables DLevel and Model . Here is the schema: (source: barramsoft.com ) Table DFile : Primary Key = DFileID Table DLevel : Primary Key = DLevelID, Foreign Key: DFileID Table Model : Primary Key = ModelID, Foreign Key: DFileID Table ELement : Primary key = ElementID, Foreign Key1: DFileID, Foreign Key2: DLevelID I have isolated the exact

In SQLServer, you can use syntax "(nolock)" to ensure the query doesn't lock the table or isn't blocked by other queries locking the same table. e.g. SELECT * FROM mytable (nolock) WHERE id = blah What's the equivalent syntax in Postgres? I found some documentation on table locking in PG ( http://www.postgresql.org/docs/8.1/interactive/sql-lock.html ), but it all seems geared at how to lock a table, not ensure it's not locked . A SELECT doesn't lock any table in PostgreSQL, unless you want a lock: SELECT * FROM tablename FOR UPDATE; PostgreSQL uses MVCC to minimize lock contention in order to

Just read this interesting article by Omar on his blog Linq to SQL solve Transaction deadlock and Query timeout problem using uncommitted reads and at the end Javed Hasan started arguing with him about his solution to the nolock situation on a high volume site. Here, the problem trying to solve is, from the sql sense we need to use Select statements with NOLOCK or use SET TRANSACTION LEVEL READ UNCOMMITTED, otherwise at high volume rows in DB will be locked and cause errors. The technology Omar used is Linq2Sql, so the question is how do we get this achieved in your C# data access code so the

I am having timeout issues and deadlocks from time to time with some long running queries. I'm wondering when is it most appropriate to use NOLOCK and where? Do I use it on the updates & inserts? or reads? Note that you can specify nolock on a per table basis. I typically used nolock in complex SELECT queries, but only for the little lookup tables that almost never changed, and for display-only data. You know the tables that list the prices for the current half year, or lookups of ids to strings etc. Stuff that only changes with major updates after which the servers are usually restarted

I have seen sql statements using nolock and with(nolock) e.g - select * from table1 nolock where column1 > 10 AND select * from table1 with(nolock) where column1 > 10 Which of the above statements is correct and why? Philip Kelley The first statement doesn't lock anything, whereas the second one does. When I tested this out just now on SQL Server 2005, in select * from table1 nolock where column1 > 10 --INCORRECT "nolock" became the alias, within that query, of table1. select * from table1 with(nolock) where column1 > 10 performs the desired nolock functionality. Skeptical? In a separate

We're evaluating EF4 and my DBA says we must use the NOLOCK hint in all our SELECT statements. So I'm looking into how to make this happen when using EF4. I've read the different ideas on how to make this happen in EF4, but all seem like a work around and not sanctioned by Microsoft or EF4. What is the "official Microsoft" response to someone who wants their SELECT statement(s) to include the NOLOCK hint when using LINQ-to-SQL / LINQ-to-Entities and EF4? By the way, the absolute best information I have found was right here and I encourage everyone interested in this topic to read this thread.