Viewing 15 posts - 50,986 through 51,000 (of 59,091 total)
Sorry for not getting back to this sooner... Barry went in the same direction that I would have. (Thanks for the honorable mention in the code, Barry :))
Karthick, look around...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 24, 2008 at 7:22 am
Heh... sorry Gus, I took it the wrong way... thought for sure it was directed at me and didn't understand why especially since you know me pretty well... thank you...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 24, 2008 at 7:16 am
Good explanations, Gus.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 24, 2008 at 7:09 am
Mahesh Bote (4/23/2008)
No cure needed... they automatically drop at the end of the proc (poet and don't know it, too!)
Thanks Jeff for updating me. I was under impression...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 6:53 am
John Mitchell (4/23/2008)
You can avoid the "speed at all cost" methodology if you want... but I'd suggest that you haven't and you won't. Considering all that you've written about...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 6:47 am
Wanna tell me what's really going on? This code has errors in it in the form of variables that were never declared. That means this code doesn't take...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 6:36 am
Heh... that's a mess, huh? And now, you understand why properly documented code and properly named columns/tables are so valuable. 😛
I'll take a look, Karthick...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 6:12 am
vyas (4/21/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 12:07 am
It's because you likely did not make a "firehose" (FAST FORWARD) cursor. The real key is, what did you write and why aren't you using set based instead of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 12:02 am
COUNT()
GROUP BY
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2008 at 12:00 am
You can just put the data in a table with the IDENTITY in forward order and the select in reverse order. Or, you could select using ROW_NUMBER OVER(ORDER BY).
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2008 at 11:59 pm
Mahesh Bote (4/22/2008)
Jeremy (4/22/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2008 at 11:56 pm
Thanks... I'll use Gus', then. I'll also throw in the dog/cat thing.
Just in some preliminary testing on 4Meg rows, I've found that the SET STATISTICS TIME ON command really...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2008 at 10:34 pm
Never mind... I got it from one of the posts above... just to make sure, you're using this from one of Gus' posts?
create table NumberClean (
Number bigint,
Clean varchar(100))
go
set nocount on
set...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2008 at 8:17 pm
So, in the million and 4 million row tests, what does your table and data look like? Are you just making a table with a Primary Key and a...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 22, 2008 at 7:43 pm
Viewing 15 posts - 50,986 through 51,000 (of 59,091 total)