Viewing 15 posts - 44,746 through 44,760 (of 59,101 total)
I agree with what's been said, already. The paradox of "emergency changes" is that's when bad code and mistakes are most likely to happen simply because there's a rush...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 3:00 pm
Bob Hovious (3/7/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:43 pm
Actually, it compresses it as it's saving it for both a time savings and disk storage savings right up front. And, restores are "snap" simple. I can see...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:35 pm
mario (3/6/2009)
thanks for the info mate...the issue was code related indeed
Two way street, please... what was that code issue and how did you fix it?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:33 pm
Thanks for the feedback, Wayne. I appreciate you taking the time as well posting your data in such a readily consumable format.
As a sidebar, even though it makes for...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:29 pm
NY153 (3/7/2009)
Thanks again.But I already asked, can we do it without putting 1 to 31 hard coded?
Absolutely... and, as Jules already pointed out, it will require the use of some...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:16 pm
I recently went through such a thing... for the second time...
It was simply "bad" code where a developer didn't understand the relationship between a few tables and created what amounts...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 2:07 pm
Actually, in SQL Server 2k5, we don't need to solve the running total problem for this because it's just a ranking problem... this should do it...
;WITH
cteGroup AS
(
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 12:38 pm
And, sorry... the running total article I wrote is in the process of being rewritten.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 12:23 pm
Bob Hovious (3/7/2009)
I do it strictly in self-defense.
BWAA-HAA!!! Me too! Let's get together and burn some ISO's sometime! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 11:41 am
Steve Jones - Editor (3/7/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 11:34 am
Bob Hovious (3/7/2009)
By an odd coincidence, I just did that. It doesn't seem to make a significant difference.
I just knew you would... that's one of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 10:41 am
Roy Ernest (3/7/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 10:35 am
Lynn Pettis (3/6/2009)
Of course, there are areas where egos are strong, RBAR solutions for one (right Jeff!).
Heh... no ego there... I let the code do the talking, as all should.
Funny...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 10:34 am
Bob Hovious (3/6/2009)
a WHILE loop may actually perform better than a Tally table on function like these
Jeff, do you know if the size of the tally table make any...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2009 at 9:06 am
Viewing 15 posts - 44,746 through 44,760 (of 59,101 total)