Viewing 15 posts - 58,321 through 58,335 (of 59,067 total)
Dave,
Very volitile subject... I got involved with a pretty big discussion on this subject before and I'll just say that, in all the "million-row" testing I did, I satisfied myself that properly...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2006 at 9:31 am
They say that one test is worth a thousand calculations and a million guesses... Noeld is correct. But don't take my word for it... I expanded my normally well behaved...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2006 at 11:03 pm
Very nice... very nice indeed...
These might execute a bit quicker... in fact, considering that they're single line formulas, you may not want to use them as functions, at all.. just...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2006 at 8:38 pm
For the data presented, this'll do it... and it doesn't assume that there will only be different 3 rows in the return...
SELECT Col1,Col2,Col3,MAX(Col4) AS Col4 FROM yourtable GROUP BY Col1, Col2, Col3 ORDER...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2006 at 6:27 am
For the data presented, this'll do it... and it doesn't assume that there will only be different 3 rows in the return...
SELECT Col1,Col2,Col3,MAX(Col4) AS Col4 FROM yourtable GROUP BY Col1, Col2, Col3 ORDER...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2006 at 6:26 am
Whether the column allows NULLs or not, the following will produce returns only if the column is NOT NULL and the column has something other than all blanks regardless of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2006 at 6:18 am
It seems like a pretty straight forward error message... your table won't allow nulls in the Status column but you're trying to add rows from data that contains no status. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2006 at 6:57 am
I understand the question but why must it be without a sub-query? Seems like a very unnecessary limitation unless you're doing this in an early version of MySQL or something...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2006 at 6:51 am
Uhhg... I know you're right and it works great, but I just can't bring myself to do it
because way deep down inside, I know...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2006 at 9:44 pm
WOW! Another myth destroyed. I was always led to believe that BCP was always faster than BULK INSERT. Phil's post
prompted me to do some long overdue testing on that fact. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2006 at 9:30 am
Try this, Donald...
select * from xyz where datefield >= DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)
AND datefield < DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)+1
The DateAdd/DateDiff thing strips the time from the date without the expense of a character conversion and without...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2006 at 7:49 pm
Finally... the voice of reason...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2006 at 7:40 pm
If the UDF returns a scalar value instead of a table datatype, it would be like saying...
SELECT * FROM ((1))
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2006 at 7:31 pm
Similar to what's already been suggested but accomplished in a single step...
REPLACE(REPLACE(@WordList,' ',' '),' ',',')
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2006 at 7:25 pm
Yes, it is wrong... it does not account for Leap Years.
The following shows an age of 55 when the real age is 2 WEEKS less than what is shown...
Declare
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2006 at 7:15 pm
Viewing 15 posts - 58,321 through 58,335 (of 59,067 total)