Viewing 15 posts - 55,486 through 55,500 (of 59,072 total)
Don't forget... Op wants numbers to restart at 1 at the beginning of each group. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:56 pm
Read the post, Joe... he's a rookie and he said he'd take the advice I gave him to format in the front end ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:54 pm
Heh... or concatenate the groups on a single line? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 11:22 am
Heh... that's why I asked to see the code... I'll be doing the ol' million row testing on these solutions tonight... Ladies and Gentlemen, place your bets ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 11:20 am
Or... just use the set based solution I provided to do the whole table at once ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 11:19 am
Using John's good test setup... this is 1 place where a triangular join may work well because the groups indicated by Col1 are so small...
DECLARE @Table TABLE (RowID int IDENTITY(1,1),...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 11:16 am
BTW... couldn't help but notice you're using @@IDENTITY... if a trigger is present, that could mess things up because @@IDENTITY returns the last id of ANY table updated. Recommend you...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 11:02 am
![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 10:59 am
You bet, Adam. Thanks for posting back.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 6:37 am
And... they're exercising! It's OK! Let 'em go...
Articles are supposed to spark conversation and your's certainly has. Take the good with the...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 6:36 am
Your point was spot on, Andy... I'm just spinning it the other way... ![]()
Step back and look at what you're doing... is getting...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 6:19 am
The formulas that both James and I wrote will automatically take care of that...
SET DATEFORMAT dmy
DECLARE @CurrentDate DATETIME
SET @CurrentDate = '27-02-2004' --Leap year
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 5:27 am
I guess I don't understand why anyone would apply foreign keys to such disposable data
Should be the other way around... 
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 5:23 am
You wouldn't actually change the format of the column... just what the results of a SELECT on the column look like... (using GETDATE() in place of a column here)...
SELECT REPLACE(REPLACE(REPLACE(CONVERT(VARCHAR(26),GETDATE(),120),'-',''),'...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 5:18 am
If the C:\User directory is on a machine other than the server, you must use the UNC format for the directory name... for example...
\\machinename\sharename\endentities.sql
... where "sharename" might be...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 5:10 am
Viewing 15 posts - 55,486 through 55,500 (of 59,072 total)