Viewing 15 posts - 55,771 through 55,785 (of 59,098 total)
I just make sure I do a copy of everything in the reply window before I hit submit... I learned that "posting" lesson on this and other forums... kinda like...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 8:37 am
Heh... that's what I get for playing devil's advocate and I should have explained more...
Thanks for filling in the details. 
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 8:33 am
Give me Info on how the two rows relate to each other
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 10:15 pm
Kinda busted a hump trying to help you get rid of the cursor on this one, Joel... any feedback? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 10:13 pm
Not sure you need that many conditions even to accomplish the 3rd condition... this should do the trick...
select count(t1.intID --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
July 17, 2007 at 10:09 pm
Vijaya,
Since you're brand new, lemme just tell you that posting data in the following manner is much more helpful to those that would help you... tell's us almost everything we...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:55 pm
Just from the practical point for ease of troubleshooting, here's from our "standards" book at work...
All column names shall be prefixed with a table alias in the presence of joins...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:18 pm
Phill is spot on. I'll kick in that BCP has some additional features that make it a bit slower than Bulk Insert (but still faster than DTS) including error logging...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:09 pm
It's not often that I see a query improve performance by applying Index Hints. Usually, it's the other way around... When you say you are seeing some impressive improvements in...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 6:07 pm
Lookup sp_Rename in Books Online... that'll do what you need...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:58 pm
... and, that's just the date... doesn't include time...
But, Serqiy is correct... there's a date format that's based on the number of seconds since the 01/01/1970. There are other "numeric" date...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:53 pm
SELECT CAST(CONVERT(CHAR(8),somedate,112) AS INT)
...but it's an insane thing to do for so many reasons...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:52 pm
Almost forgot to ask... I know you said you can't normalize the table (would be the greatest space saver of them all here) so I won't bug you about that... but...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:46 pm
Using LTRIM(RTRIM()) will not make NULLs... that may be a part of the problem... here's the proof...
DECLARE @NullOrBlank VARCHAR(8000)
SELECT @NullOrBlank = REPLICATE(' ',100)
SELECT DATALENGTH(@NullOrBlank) AS DataLengthBefore,
...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:44 pm
It wouldn't be a "sum"... it would still be a COUNT except it wouldn't be DISTINCT. And, because you are not counting DISTINCT LID's, you already have the sum of...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:30 pm
Viewing 15 posts - 55,771 through 55,785 (of 59,098 total)