Viewing 15 posts - 41,056 through 41,070 (of 59,069 total)
Michael Meierruth (11/21/2009)
Jeff Moden (11/21/2009)
Michael Meierruth (11/21/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2009 at 10:33 am
Like I said... very cool that you busted a hump helping yourself, Andy.
Here's a slightly (radically, actually) different approach that uses "Divide'n'Conquer" methods... the details are in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2009 at 9:01 am
Actually, thank YOU! It's really nice to see someone take a simple hint, do a bit of research, and then actually post a viable solution that's actually readable. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2009 at 7:45 am
Joe Celko (11/21/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2009 at 7:36 am
Michael Meierruth (11/21/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2009 at 7:28 am
chandrashekar,
It would be much better if you talked to the owners of the original table and got them to normalize that terrible CSV column. If you can't do that,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 11:01 pm
Nabha (11/20/2009)
MY bad! go with Vikas, that is the right solution for you.
Heh... no it's not...that function has a While Loop in it and it's going to be slow. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:53 pm
chandreshgeria (11/20/2009)
I think that what you have given is to lengthy process i give procedure of my way how i calculate running total
-------------------
drop...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:46 pm
BWAAA-HAAA!!!! :hehe: Thanks for posting the answer you got but if you had posted data that way in your original post, you'd have had an answer on this...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:39 pm
Credits to Navy beans says that the clustered index is on something non-temporal and you're killing the system with page-splits. Page splits stop when you delete some of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:23 pm
You don't need a function for this... use the last query in your code example and mix the case statments into that so you do things quickly in a set...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:16 pm
DBTeam (11/20/2009)
Thank u So much for all ur sugesstions,i'll create unique index only
If you have no clustered index, index maintance won't be worth much on a 70 million row heap....
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:09 pm
Bru Medishetty (11/18/2009)
In your case, it is better to have a unique constraint enabled rather than having a primary key (Since it is nvarchar(255).
Ummmm.... not necessarily true. A non-clustered...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 10:05 pm
You'd probably have better luck if you spent some time with Google...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 9:55 pm
AhTu_SQL2k+ (11/19/2009)
It takes about 38s to return 36,000+ rows at the moment and I expect it will become even slower as the tables size are increasing.
Heh...hold on a minute......
--Jeff Moden
Change is inevitable... Change for the better is not.
November 20, 2009 at 9:50 pm
Viewing 15 posts - 41,056 through 41,070 (of 59,069 total)