Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Erland Sommarskog Newsgroups: comp.databases.ms-sqlserver Subject: Re: Select affected rows Date: Tue, 7 Feb 2012 12:56:14 +0000 (UTC) Organization: Erland Sommarskog Lines: 23 Message-ID: References: <93b61b75-3623-40cb-943e-84afb1451403@dp8g2000vbb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Tue, 7 Feb 2012 12:56:14 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="G7+Jz22XqYCG8C6rb1H3YA"; logging-data="7304"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18kTz4gjlCWLKg7eZa5ykYb" User-Agent: Xnews/2005.10.03 Mime-proxy/1.4.c.4 (Win32) Cancel-Lock: sha1:X1pSZjYy30SdK/RY5YOXWw1u8M0= Xref: x330-a1.tempe.blueboxinc.net comp.databases.ms-sqlserver:928 omtechguy (omtechguy@gmail.com) writes: > Another question, is there an (NOLOCK) equivalent option for update > statement? You can use NOLOCK in an UPDATE statement, even with the table you are updating. But of course it does not have any effect. Overall, NOLOCK is nothing to use at routine, but you need careful understanding of the consequences. Not only can you happen to read uncommitted data, but you also fail to read existing and committed data, which can lead to seriously incorrect results. If you have problems with locking, you should explore the database setting READ_COMMITTED_SNAPSHOT. When this setting is in effect, readers to not block writers and vice versa. -- Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx