Viewing 15 posts - 58,471 through 58,485 (of 59,067 total)
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
It's easy with a Tally (or Numbers) table...
--===== This is just part of the test setup...
--===== If experimental tables exists, drop them
IF OBJECT_ID('TempDB..#yourtable') IS NOT NULL
DROP...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 15, 2006 at 9:12 am
Is is "death by SQL" to change the Server Wide Setting but if you insist on a certain proc being able to evaluate IF NULL=NULL, then you can use SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 15, 2006 at 8:55 am
Outstanding Gail... I forgot about the batchsize thing... to take that a bit further, I used BCP for a similar requirement with 40 million rows... Using a batch size of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 13, 2006 at 6:37 am
The SELECT/INTO works very fast because the new destination table has no indexes to update and no check constraints.
If you add the WITH (NOLOCK) hint to the FROM clause,...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2006 at 9:33 pm
You say 'em, I'll make 'em. What a team!
The neat thing here is that using NEWID as the seed for RAND allows true...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2006 at 11:22 pm
Here's a set-based method...
SELECT CHAR(RAND(CAST (NEWID() AS VARBINARY))*26+65)
+ CHAR(RAND(CAST (NEWID() AS VARBINARY))*26+65)
+ CHAR(RAND(CAST (NEWID() AS VARBINARY))*26+65)
+ CHAR(RAND(CAST (NEWID() AS VARBINARY))*26+65)
+ CHAR(RAND(CAST (NEWID() AS VARBINARY))*26+65)
+ CHAR(RAND(CAST (NEWID()...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2006 at 9:16 pm
Yeaup! That's the one!! You were there, too, Jesper... way too much fun!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2006 at 9:01 pm
Here's one that absolutely rocks! I don't remember the person who wrote it originally, but the two of us played with it and it generates a list on a million...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2006 at 5:54 pm
We call it the "Easy button"... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2006 at 5:48 pm
Viewing 15 posts - 58,471 through 58,485 (of 59,067 total)