Viewing 15 posts - 55,516 through 55,530 (of 59,098 total)
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
By the way... not my job to say so but I like the format of your code... nice and easy easy to read even when not in Courier 
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:57 am
Heh... oh what a smile your brought to this ol' man's face this morning! Thanks for the laugh, James!
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:55 am
Still waiting here on Earth... why would you want to swap data between two obviously disparate tables?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:53 am
I don't know what you mean by "Depending if is bissextile year or not", but here's an example of the formulas you could use... replace @CurrentDate with GETDATE() and it...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2007 at 4:30 am
Viewing 15 posts - 55,516 through 55,530 (of 59,098 total)