﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Harsha Majety  / Implementing Queuing Mechanism / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Fri, 24 May 2013 21:41:05 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Implementing Queuing Mechanism</title><link>http://www.sqlservercentral.com/Forums/Topic1140162-2846-1.aspx</link><description>Trying the test again, but with 2 windows both running your original script concurrently, then both updated 255 rows every time.I can't explain this, but it must be something to do with the locking (??!)</description><pubDate>Tue, 12 Jul 2011 04:03:39 GMT</pubDate><dc:creator>paul_ramster</dc:creator></item><item><title>RE: Implementing Queuing Mechanism</title><link>http://www.sqlservercentral.com/Forums/Topic1140162-2846-1.aspx</link><description>That logic can be done in one single update (which doesn't require any particular locking strategies or isolation levels):[code="sql"]DECLARE @nextMergeID INT ;DECLARE @customerID INT;DECLARE @mergeDate DATETIME;DECLARE @reset BIT;UPDATE dbo.merge_standard_queue SET @nextMergeID = merge_id, picked = 1, lub = 'v2'WHERE merge_id = (select top 1 merge_idfrom dbo.merge_standard_queuewhere picked = 0order by merge_date asc);GO 255[/code]testing your method against the above single update, I created a merge_standard_queue table:[code="sql"]drop table dbo.merge_Standard_QueueGOcreate table dbo.merge_standard_queue ( merge_id int identity(1,1) not null primary key, merge_date date not null, picked bit not null, lub varchar(10) null)GOINSERT INTO dbo.merge_Standard_Queue (picked, merge_Date)select 0, DateAdd(day,t.Number, '2010-01-01')from tally tGO[/code](my tally table has 32,767 rows, so that's a reasonable size to test against).Then I opened two separate windows in SSMS, one with your script (amended to set lub to 'v1'), and one with the single update version above, and ran them both 255 times concurrently (with a GO 255).The results were interesting... Both reported "Batch execution completed 255 times.", but your script never updated 255 rows, whereas the single update statement always updated 255 rows every time.[code="sql"]select lub, count(*) from dbo.merge_standard_Queue group by lub[/code]returned (as an example, the actual number of updated rows varied between iterations)[code="other"]lub	(No column name)V1	238NULL	32275v2	255[/code]</description><pubDate>Tue, 12 Jul 2011 03:59:26 GMT</pubDate><dc:creator>paul_ramster</dc:creator></item><item><title>Implementing Queuing Mechanism</title><link>http://www.sqlservercentral.com/Forums/Topic1140162-2846-1.aspx</link><description>Comments posted to this topic are about the item [B]&lt;A HREF="/scripts/Database+Design/74685/"&gt;Implementing Queuing Mechanism&lt;/A&gt;[/B]</description><pubDate>Tue, 12 Jul 2011 01:42:26 GMT</pubDate><dc:creator>harsha.majety</dc:creator></item></channel></rss>