# SQL Server Rule: SRD0034
| | |
|----|----|
| Assembly | SqlServer.Rules |
| Namespace | SqlServer.Rules.Design |
| Class | DoNotUseNOLOCKRule |
## Rule Information
| | |
|----|----|
| Id | SRD0034 |
| Friendly Name | Use of NOLOCK |
| Category | Design |
| Ignorable | false |
| Applicable Types | Procedure |
| | Scalar Function |
| | Table Valued Function |
| | View |
## Description
Do not use the NOLOCK clause.
## Summary
Do not use the NOLOCK clause
### Examples
```sql
CREATE PROCEDURE dbo.TestWithNoLock
AS
SET nocount on
SELECT idcol FROM dbo.TestTableSSDT WITH(NOLOCK)
GO
-- SML003, SRD0034
```
### Remarks
- **Dirty read** - this is the one most people are aware of; you can read data that has not been committed, and could be rolled back some time after you've read it - meaning you've read data that never technically existed.
- Missing rows - because of the way an allocation scan works, other transactions could move data you haven't read yet to an earlier location in the chain that you've already read, or add a new page behind the scan, meaning you won't see it at all.
- Reading rows twice - bimilarly, data that you've already read could be moved to a later location in the chain, meaning you will read it twice.
- Reading multiple versions of the same row - when using READ UNCOMMITTED, you can get a version of a row that never existed; for example, where you see some columns that have been changed by concurrent users, but you don't see their changes reflected in all columns. This can even happen within a single column (see a great example from Paul White).
- Index corruption - surely you are not using NOLOCK in INSERT/UPDATE/DELETE statements, but if you are, you should be aware that this syntax is deprecated and that it can cause corruption, even in SQL Server 2014 RTM - see this tip for more information. Note that you should check for the hint in any views that you are trying to update, too.
<sub><sup>Generated by a tool</sup></sub>
