Viewing 15 posts - 54,676 through 54,690 (of 59,098 total)
... and that was my point... not all Dynamic SQL is bad nor even indesireable.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2007 at 5:56 am
So far, nobody can explains to me that my original query with INNER JOIN doen't works and without INNER JOIN, works very nice.
... and you haven't posted the real life...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 10, 2007 at 5:21 pm
Please provide the code and data that demonstrates when the correctly specified Update and Index fails. Then provide your correct Order By method that solves the problem.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 10, 2007 at 7:18 am
The code you have is the classic code necessary to put records together from multiple rows in a name/value table. It's actually pretty darned fast... only thing faster would...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 10, 2007 at 6:41 am
Sarvesh,
First... when you get an error, you need to post it so we can see what's going on.
Second... are you actually using SQL Server 2005?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 10, 2007 at 6:29 am
Saritha... it would be really nice if you shared how you solved it. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:50 pm
No... if you're talking about simple duration measurements, it's not useless... you've just gotta make sure they're either both "hot" or both "cold" 😛
But, in the face of blocking, looking...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:30 pm
Heh... Thanks, Noel... I keep forgetting to check the date on the original post...
Oh well... keeps my hand at typing and I have seen it where the OP actually...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:28 pm
The update method works well, in all cases... and it does NOT depend on a Clustered Index... just SOME index.
You just need to settle down, maybe have a beer, and...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:22 pm
Hey folks... I had reason to revisit this post to demo to someone else... I don't know what change was recently made to the 2k server I work on but...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 9:46 pm
Linda Robinson (10/9/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 5:57 pm
Tomm Carr (10/9/2007)
Alpha or alpha-numeric keys are not significantly slower than numbers, ...
You certainly did take that one out of context...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 5:52 pm
The real problem is that you're trying to solve two different problems at once... divide and conquer... the code will not only be faster performance wise, it will also be...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 5:00 pm
I'm by no means making fun of you, Linda... but the polar ice caps are retreating faster than "200 rows per minute" and it's why I don't like things like...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:26 am
Matt is correct about needing the CASE... but I'm not sure why we need the #Summary table, at all...
First, a brief lesson in creating massive amounts of test data in...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 9, 2007 at 10:14 am
Viewing 15 posts - 54,676 through 54,690 (of 59,098 total)