Heh... deletes make me nervous, anyway... constitutes some form of lost data. I don't use cascade deletes because I want people to have to work at doing deletes. ...

If memory serves correctly, I believe that form of index hint is "deprecated". Try this, instead...

select ACCT_NUM, OPERATOR_NUM, BRANCH_NUM

from TRANS_J_DATA_FULL WITH (INDEX(IX_TRAN_FULL))

where TRANS_DATE >= @dStartDate and TRANS_DATE <= @dEndDate...

Don't use either... use the functions built for this...

1. Check if temp table exists...

IF OBJECT_ID('TempDB..#temptablename','U') IS NOT NULL

PRINT 'Table Exists'

...

Heh... in other words, there's no such thing as a Julian date of "107999"... can only go up to 107365... next day would be 108001.

With that in mind, the following...

How did it help? What was the problem?

Never import directly to the final destination table... import into a staging table... should be able to use a default on a staging table but, if not, just update the...

Two way street here... please share your solution.

Heh... do you intend to print that size sheet?

Test the code in the presence of the indexes and not... that's the only real way to tell.

That's one of the best compliments anyone could ask for, James. Thank you, Sir!

14k characters? What on earth are you doing?

Still, Exec will handle many more than 14K characters... so that's not the problem. Can't tell what's causing the problem 'cause...

Please share what you did...

Both will take the same time because EM7 will run the same code as what you've typed behind the scenes...

Yes, thank you for the feedback and I agree that a clustered index will, in fact, make the concatenation run much faster... except that most folks aren't going to dedicate...

Well, kind of... before SQL Server 2000, there was no such thing as user defined functions... people ended...