Viewing 15 posts - 58,486 through 58,500 (of 59,091 total)
Like I said earlier... the hard knocks code will beat the pants off DTS either way. Thanks for the feedback Greg. You can get some extra performance out of SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2006 at 8:20 pm
>>>These temp tables can then be cursored...
I don't think you understood... the whole idea is to get rid of cursors and other RBAR methods in SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2006 at 7:37 pm
>>But for this type of operation, I still think xp_execresultset is the best solution.
The original post was for "Eliminating Cursors" so I have to ask... how do you use it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2006 at 7:34 pm
Just my humble opinion but I need to clear up some of the myths associated with Table Variables...
First, table variables don't live in memory anymore than temp tables...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2006 at 6:23 am
Thanks for coming back, John...
Yeah, I saw your original post where you said you had a table with all of the individual possible values. Your solution looks as though it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2006 at 8:08 pm
Greg,
I don't know if having the Primary Key on the last column will affect performance especially for CLUSTERED keys... I'd have to study the format in BOL a bit.
However,...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2006 at 7:48 pm
Gail,
You wrote "ps, I don't understand your comment about pushing into a table without a pk. Best insert performance is a when inserting into a heap with no indexes".
Normally I...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2006 at 7:45 pm
Then something else went wrong, Gail. Perhaps there was a cross-join in the code. Perhaps you had a bad connection (it happens). Perhaps the linked server was not setup correctly. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2006 at 5:48 am
Not sure why that would matter at all but OK, whatever you say. I was thinking that maybe the servers had some different settings (like collation and memory allocation), a...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 9:22 pm
Uh... if you're new, it'll take a bit of study on your part, but you may want to consider setting up "replication"... then, it's nearly "auto-magic" from there. The steps...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 9:10 pm
Well, thanks Greg. I'm thinking that 35 seconds including the addition of a Primary Key isn't too bad (1.37 million rows per minute). I love it when DTS looses (and it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 9:04 pm
If you truly want to synchronize, why not just generate all the code for sprocs, views, and udf's in Enterprise Manager and let 'er rip?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 8:44 pm
Ok, then... you ask a question, I bust a hump giving you a pretty good answer... did it work for you or what?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 8:42 pm
Milovan,
I noticed that all of the other solutions, although well written and functional, contain WHILE loops. Inherently, WHILE loops are slower than setbased code especially if you have a lot...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 8:13 pm
To do this, you will need a BCP format file OR, lose the IDENTITY column. BCP Format files can actually do all of the parsing in the final format for...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2006 at 7:32 pm
Viewing 15 posts - 58,486 through 58,500 (of 59,091 total)