Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m having the following issue:
I’m inserting a row to table (say, ‘temp’) inside a transaction (default ADO.NET transaction). Until that transaction is committed, the command ‘select * from temp’, running from another session (SQL Server 2008 management studio), is blocked and cannot be completed.
This seems weird to me. Shouldn’t the read command return all the previous table rows (everything but the newly inserted row) and not get blocked?
The default behaviour in SQL Server is to take locks, and these will not be released until the transaction is committed.
There are 3 main ways around this – the READPAST hint (which will skip the locked row(s)), the READ UNCOMMITTED isolation level (or NOLOCK hint) (which will return all rows, including the newly inserted one(s), or the SNAPSHOT isolation level – but for snapshot to work, this needs to be enabled at the server level