SQL Transactions with nolocks and TRANSACTION ISOLATION LEVEL READ COMMITTED - sql

Question

I have a stored procedure like this.
CREATE PROCEDURE [dbo].[mysp]
AS
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN
BEGIN TRAN
DECLARE #TrackingCode INT
SELECT #TrackingCode = DefaultsData
FROM dbo.Defaults
WHERE DefaultsID=77
UPDATE dbo.Defaults
SET DefaultsData = #PassedTrackingCode+1
WHERE DefaultsID=77
SELECT #TrackingCode
COMMIT TRAN
END
Assuming that we execute this stored procedure at the same time (concurrently) twice, what will be the #TrackingCode value that is returned at both the time. What if I used NOLOCK on the SELECT statement in the stored proc.

Answer 1

1) If your intention is to generate unique tracking codes then it's a bad idea. You could do this simple test:
CREATE TABLE dbo.Defaults (
DefaultsData INT,
DefaultsID INT PRIMARY KEY
);
GO
INSERT INTO dbo.Defaults VALUES (21, 77);
GO
CREATE PROCEDURE [dbo].[mysp]
AS
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN
BEGIN TRAN
DECLARE #TrackingCode INT
SELECT #TrackingCode = DefaultsData
FROM dbo.Defaults
WHERE DefaultsID=77
WAITFOR DELAY '00:00:05' -- 5 seconds delay
UPDATE dbo.Defaults
SET DefaultsData = #TrackingCode+1
WHERE DefaultsID=77
SELECT #TrackingCode -- Maybe it should return the new code
COMMIT TRAN
END;
GO
and then open a new window in SQL Server Management Studio (Ctrl + N) and execute (F5)
EXEC [dbo].[mysp]
and also open a second new window and execute (in less than 5 seconds)
EXEC [dbo].[mysp]
In this case, you will get the same value. NOLOCK is a bad idea (generally speaking) and in this case doesn't help you.
2) If (I repeat my self - sorry) your intention is to generate unique tracking codes then you could use
ALTER PROCEDURE [dbo].[mysp]
#TrackingCode INT OUTPUT
AS
BEGIN
SET NOCOUNT ON;
UPDATE dbo.Defaults
SET #TrackingCode = DefaultsData = DefaultsData + 1 -- It generate the new code
WHERE DefaultsID=77;
END;
GO
or you could use sequences (SQL Server 2012+).