Viewing 15 posts - 36,631 through 36,645 (of 59,072 total)
I was going to suggest that if the app likes the "natural" order up to now, have the app read the data from the table into a new table to...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:36 pm
Barkingdog (9/19/2010)
You wrote
>>> At any rate, the WORST thing you could possibly do is use a BEGIN TRANSACTION on this problem.
Why is that the case?
In fact, my solution is exactly...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:32 pm
Barkingdog (9/19/2010)
My solution is the same as yours except I used:
SELECT @return= NextID FROM seqNum with (UPDLOCK)
Given the table has only a single record I think the solutions are equivalent....
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:28 pm
Heh... I'm just a step behind you on my posts...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:20 pm
Craig Farrell (9/19/2010)
Btw, if you force the tablockx, you...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:18 pm
Ah... to be sure... the "Kalpa Shah" that I refer to in the revision history was one of the two Systems DBA's I was working with on this problem. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:15 pm
It's the combination of SELECT/UPDATE inside of an explicit transaction that produces the deadlocks just like at the company I was telling you about. If the following is kept...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 8:05 pm
Heh.. been there and done that. Use to work for a "little" DOD shop known as Raytheon. 😛
The only way that I can think of to make this synchronus...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 7:41 pm
brianparow (9/19/2010)
ie:
123.txt and 123.pdf
I...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 7:20 pm
Craig Farrell (9/19/2010)
...think that old guy with the cell phone you can use as a doorstop... 🙂
Hey now! Watch it! I strongly resemble that remark! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 6:54 pm
Dang... I reviewed an article for someone on Sequence tables and now I can't find it.
At any rate, the WORST thing you could possibly do is use a BEGIN TRANSACTION...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 6:52 pm
I'm not sure (CRS), but I think Paul White may have written an article on this subject. I'll see if I can find it.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 6:42 pm
Barkingdog (9/19/2010)
You wrote
>>> CREATE TABLE FooBar (FooBarID INT IDENTITY( 1, 1), <tabledef>) should work just as well. If it's a matter of needing to know the ID for multiple inserts,...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 6:39 pm
I don't know if it will help your deadlock situation but you're asking for a world of hurt with how you're doing the deletes. If you look in Books...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 6:31 pm
To add to what Adi has already stated, in SQL Server 2000, SET XACT_ABORT ON became one of my very best friends as a not-so-good attempt at Try/Catch. As...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2010 at 5:48 pm
Viewing 15 posts - 36,631 through 36,645 (of 59,072 total)