SQL Server engine errors
SQL Server 1934 Update Conflict
Reviewed for reference consistency: April 11, 2026
Update Conflict — the row was modified by another transaction after being read
What 1934 Means
The 1934 error on the SQL Server engine errors indicates update conflict — the row was modified by another transaction after being read. This typically occurs due to two concurrent transactions modify the same row under snapshot isolation.
Error 1934 occurs under snapshot-based isolation levels when a transaction attempts to update a row that another committed transaction has already modified since the snapshot was taken. It is a concurrency control mechanism.
How to fix 1934
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Set the required session options
Operations on indexed views, computed columns, and filtered indexes require specific SET options. Enable them for the connection before the statement runs.
SET QUOTED_IDENTIFIER ON; SET ARITHABORT ON; SET ANSI_NULLS ON;Check the options your session actually has
Confirm which options are active so you can see what differs from the required set.
DBCC USEROPTIONS;Add retry logic for snapshot conflicts
Under snapshot isolation, catch the conflict, re-read the latest row version, and retry the update a limited number of times.
Keep write transactions short
Read the row again right before writing and commit quickly to shrink the window where another transaction can change it.
Technical Background
Error 1934 is specific to snapshot-based isolation levels (SNAPSHOT and READ_COMMITTED_SNAPSHOT with certain operations). Under these models, SQL Server keeps row versions in tempdb. When a transaction tries to update a row whose version has changed since the snapshot, the engine raises 1934.
This is a classic 'first writer wins' conflict. Unlike pessimistic locking (which blocks the second writer), optimistic isolation allows both readers to proceed but rejects the second writer if a conflict is detected at commit time.
Common Causes
- Two concurrent transactions modify the same row under snapshot isolation
- An optimistic concurrency check detects a version mismatch
- A long-running read transaction conflicts with a committed write
Typical Scenarios
- Two users edit the same record simultaneously in an application using SNAPSHOT isolation
- A background batch process updates rows while an interactive session holds a snapshot of the same data
What to Know
Applications using snapshot isolation should include retry logic for update conflicts. The pattern of catching error 1934 and re-reading the latest row version before retrying is the standard concurrency conflict resolution approach.
Frequently Asked Questions
Common questions about SQL Server 1934 error
A deadlock (1205) occurs when two transactions are waiting on each other's locks. Error 1934 is an optimistic concurrency failure where the second writer is rejected because the data changed after the snapshot was taken.