No, Sir, David... you're not wrong... but not for the reasons you state...

First, let's build a small table of only 10,000 rows with only the data with which we are...

Yeah... that's what I mean Stuff like that...

Heh... my boss' boss says that all the time... it's why our projects seem to go in so fast... who cares if it takes six months extra to fix what we...

Thanks, guys.  Yeah, the only thing I could think of was a minimal logging bulk insert staging table but he's not using it for that...  it's a permanent cross-reference table...

Who are you and what have you done with the real Serqiy?  The real Serqiy I know would have said something about going back and fixing the database so there...

Don't use ISQL.exe for any batch process... it is severely deprecated... use OSQL.exe instead.

I'm thinking somebody is going to need a comma or two in there

Please explain what you mean by "when it rolls over into the next range".  Also, it's been 2 months and you still haven't posted the exact error message.  Might also...

While this may sound incredibly simple, it is also incredibly common... have the network guy check the "duplex" on all the "boxes" in the connection chain to that remote server......

I think "business intelligence" is a bit of an oxy-moron when it comes to management... if you can't get them to invest in intelligent/skilled people to run and protect their...

Just my 2 cents... My testing shows that following all have identical execution plans and they all take an average of 1004 milliseconds to run...

DECLARE @BitBucket  INT

--===== WHERE...

Timeouts frequently have nothing to do with duration.... sometimes if tables are locked for update by a long running explicit transaction, you can get a timeout almost immediately.

Also, don't forget... that if you have any VARCHAR columns > 4000 characters, you could have a serious problem with truncation...

And please provide the query that allowed you to select which rows you want deleted!  Stop making us guess!

Nah... you can get INDEX SEEKS out of non-clustered indexes... they just won't be CLUSTERED INDEX SEEKS.  And, (as you know, ol' friend), I don't think they'll come close to...