Viewing 15 posts - 56,281 through 56,295 (of 59,070 total)
Tomm's code for an upsert is good... think I'd do it in a stored procedure rather than DTS, but it'll do the trick either way.
I still use BULK INSERT and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 7:26 pm
Heh... you're welcome, Chris...
But that's just step one... (make it work)
Here's the code to generate a million row test table for step two... (make it work fast) ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 8:28 am
![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 7:26 am
Absolutely agree with that!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 7:21 am
Now, wouldn't it be an absolute hoot if they were looking at the MSDE box in Query Analyzer or EM thinking that it was the production box? Not so uncommon a...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:31 am
Concur... that's just about the same as what I use for header info. And I document any parameters where such documentation belongs... next to the parameters in the code --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
May 30, 2007 at 1:23 am
Heh... cursors... gotta love 'em.
How much disk space do you have... 300 gig? 500 gig? Why are you worried about a 9 or 10 gig TempDB? Shoot... we preset ours...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:15 am
Why speculate
Do a test
Run the following code several times and tell your team mate "Sorry,...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 1:04 am
That certainly doesn't help the rest of us... Please post the "e-mail w/ example" here ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:27 am
Just like anywhere else... build a calendar table and a separate holiday table... include holidays for every country and make sure the holiday table has the ISO country code in...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:25 am
Dinendra,
We need to know why you want to do this so we can give you the most correct answer.
(Thats' why, Ben
)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:14 am
You might be able to use some form of recursive CTE in SQL Server 2005, but your request is in an SQL Server 2000 forum.
The UDF that David suggested...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2007 at 12:03 am
I am amazed at how many applications I see with a stored procedure that has a single record... |
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:53 pm
...and, if there hasn't been too much activity, you may be able to recover the MDF and LDF files if they were, in fact, deleted.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:33 pm
Add an Identity column and delete the dupes when the import is done... much faster than trying to build an "UPSERT" (merge) in SQL Server 2000.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2007 at 11:31 pm
Viewing 15 posts - 56,281 through 56,295 (of 59,070 total)