Viewing 15 posts - 51,286 through 51,300 (of 59,091 total)
More on the above... try solving the running total problem in 3 or 4 different RDBMS engines... and still have some scalability and performance left over.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2008 at 8:19 am
Portability? Have you ever tried to make 100% portable code and still have it actually do something more than return data to a GUI with simple SELECTs? Even...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2008 at 8:18 am
I agree... like I said, not sure why I even posted the implicit code... I don't trust defaults for the same reasons you don't.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2008 at 7:56 am
Very good point.
Actually, I'm not even sure why I posted the implicit conversion code... Implicit conversions constitute a "default" of sorts and I've seen MS change a couple of defaults...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2008 at 5:57 am
JohnG (4/2/2008)
Yes... don't use either... use an INNER JOIN instead
Not always. The matching values resulting from an INNER JOIN can be more than one (1). This will result...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2008 at 5:34 am
Antonio,
Your solution doesn't work with the test data I created. Please post your test data generator and the result times you got.
Gus, you're splitting out more than requested and...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 10:31 pm
GSquared (4/2/2008)
Jeff, please tell me what I got wrong on the Numbers table version
At a high level, yes... You split on the "&" instead of the "=" which forces you...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 10:27 pm
Oh, I agree... first step towards some sort of performance is to reduce the number of cursors and UDFs to zero by using the rCTE.
Second step would be to think...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:54 pm
All the code blocks in that link show up as little red x's for me...
The thing I'm concerned about is that the word "loops" was mentioned in the test... testing...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:49 pm
Heh... nope... different guy :hehe: ... the other one knew a lot more about the system... this one is on a steep learning curve for 2k5 and has seen the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:42 pm
It is amazing that two copies and truncate could be so fast. Guess that's why lot so folks use it... so long as there aren't foreign keys, delete triggers,...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:36 pm
Sounds like a winner, J. Thanks for sharing the tips.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:32 pm
Steve Jones - Editor (4/2/2008)
Heh... nope... me and my friends used to jump off bridges for fun... Mom didn't mind because we...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:31 pm
Steve Jones - Editor (4/2/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:25 pm
ALZDBA (4/2/2008)
And I've always been trying to avoid implicit conversions ......... :hehe:
Apparently, even on a million rows... makes no moxnix...
DECLARE @Bitbucket datetime
SET STATISTICS TIME ON
SELECT @Bitbucket = DATEADD(mm,1,EndDate+'01')-1
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2008 at 2:21 pm
Viewing 15 posts - 51,286 through 51,300 (of 59,091 total)