Viewing 15 posts - 51,676 through 51,690 (of 59,098 total)
I think you may have a misunderstanding of what it does... VarDecimal has nothing to do with the MONEY datatype. The only time that VarDecimal saves space is if...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 3:23 pm
Did you look at the "Message" window? Sometimes one or the other runs in half the time as the other. Some folks look at something like that on...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 3:15 pm
Perfect... the next thing to do would be to practice a little of what we call "forum etiquette"... 😉 How did you solve it and would you mind posting...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 3:06 pm
Heh... No doubt... I can see the RBAR on steroids now... some of my favorite misuses are SPLIT/CONCATENATION functions in batch code, UDF's that format dates so they can be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 3:04 pm
And then you better make sure you run the code more than once, even on a quiet system...
DECLARE @Year INT
SET @Year = 2008
SET STATISTICS IO ON
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 2:46 pm
LMAO!!! ROFL!!! Now that's funny stuff... I don't care who you are, ya gotta laugh at that! (Thanks for the quote Larry TCG). 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 2:33 pm
Chris Morris (3/18/2008)
Jeff, you like playing with macros in Excel
Heh... no I don't... I hate the darned things... That's why I like the second of my two methods the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 2:29 pm
I agree with the others... find and fix the problem... and, Know this... Setting the Transaction Isolation Level and using WITH (NOLOCK) is NOT a panacea for fixing deadlocks.
We were...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:44 pm
Sorry... forgot to add the line that makes it more than twice as fast...
DECLARE @Year INT
SET @Year = 2008
;WITH cteDates AS
(
SELECT DATEADD(yy,@Year-1900,0)+Number AS TheDate
...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:32 pm
Matt is absolutely spot on. Without actually getting into using a Tally table to do this, here's one way to programmatically generate a Year's worth of dates using a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:20 pm
Just my 2 cents... I'm always pretty much amazed at such requests... I do one of two things in most cases where someone "has to have it" in an Excel...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 12:05 pm
In other words, Dragon3486... messy code is hard to troubleshoot. 95% of all such simple syntactical problems can easily be avoided altogether if you format your code in an...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:55 am
More likely, since you said you had the window open for days, the data in the tables the view references changed. Doesn't take a lot... if your execution plan...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:50 am
And, the "re-used" execution plan for 1 set of parameters might be absolutely terrible with another set or sometimes a thing called "parameter sniffing" kicks in and the whole server...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:46 am
If, what you really mean, is that you don't want anyone to be able to "steal" your code, then you must check all of your code into some safe place...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2008 at 11:40 am
Viewing 15 posts - 51,676 through 51,690 (of 59,098 total)