Viewing 15 posts - 47,356 through 47,370 (of 59,099 total)
Absolutely correct on all accounts, Steve... suggestions very similar to yours were made by myself and others but to no avail. I'm amazed at the number of managers have...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 9:32 am
Mohit (11/9/2008)
Thank-you for the comments, I didn't think RBAR would be big issue in my case because the table had limited number of rows and wasn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:47 am
That sounds more like problems with a table variable. Why aren't you using a temp table, instead?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 6:05 am
yep... paste the following into the "help" url box...
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/d4c26311-d9f4-432c-953a-1c1042b33c97.htm
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2008 at 10:15 pm
Kishore.P (11/7/2008)
use COALESCE function instead of IsNull or NullIf.
Why? NullIf is nothing like IsNull or Coalesce and the idea of code portability is a myth.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2008 at 10:11 pm
I'm all for normalizing data... but if no one is going to use the normalized form, then you shouldn't bother. In this case, it actually provides a negative ROI...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2008 at 9:49 pm
SQLBOT (11/8/2008)
LOL,yes, yes... touche
In those cases when I'm strapped for extra 208k of disk, I usually drop the clustered index.
~BOT
Heh... Like you say... touche`. You're absolutely correct about...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2008 at 9:30 am
You bet... thanks for the feedback, Timothy.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 8, 2008 at 7:47 am
Because, contrary to popular belief, Clustered Indexes are NOT totally contained in the data at the Leaf level... there is an Intermediate Level containing index rows AND a Root Level,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 7:14 pm
Robert klimes (11/6/2008)
And after further investigation the number of parsed coulmns will be static.
So... how many columns?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 6:55 pm
cliffb (11/6/2008)
Jeff Moden (11/6/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 6:20 pm
Thanks... and that's a very appropriate use for that code. If it was a huge table with large gaps, I was gonna suggest a different way.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 6:17 pm
David Jackson (11/7/2008)
I particularly like the date formatting trick. Why didn't I think of that! :w00t:
Many thanks Hugo. I'll run the extract later today and post some...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 6:12 pm
tony rogerson (1/16/2008)
The derived table itself is just expanded into the main query (just like a view) this means that there are no statistics available for the derived table.Tony.
I'm not...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 5:57 pm
SQLBOT (11/7/2008)
even then a clustered index doesn't hurt because it doesn't take up extra space.~BOT
Any bet's on that? 😉
USE TempDB
GO
--===== Create and populate a 1,000,000 row test table.
...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2008 at 5:34 pm
Viewing 15 posts - 47,356 through 47,370 (of 59,099 total)