Personally I'd never touch the sp_OAxx procs, they're just too much risk crashing the entire server imo...

Granted, this is a personal opinion only

On...

This is an 'old' problem - when a Transact SQL statement refers to a non-existing or non-responding remote server, it aborts hard. AFAIK, there's not much you can do about...

Well, you haven't told us what the error is. It's quite possible that you never get to the printstatement as long as there is an error.

For debug purposes it's easier...

That is not correct. The timestamp datatype doesn't contain any information pertaining to the dimensions of time as we mere mortals view it. Timestamp is simply a random value without meaning, it's...

You are aware that by updating 'House' to 'Home' you are in fact also changing the Primary Key for that record? Have you carefully analyzed what the consequences of such...

No answer to the debug question (I don't use it - always use print statements as Kathy suggested),  I just have one comment about the code (since we're in learning...

Seems to me that the FTP server is closing the connection after n time (ie shutting down the connection as 'idle'). Probably the FTP sees the connection as idling even though...

I have no experience in dealing with taiwanese (or similar) collations, but when I need to move data from one server to another (eg ANSI to OEM), I just bcp...

Is this 'central system' a production system? If it is, then don't try to connect test with production in any sort of way! Test and Prod never ever should have...

Absolutely correct.

However, not as an option, but as a requirement. The third option you mentioned is the only 'proper' one.

/Kenneth

And, to help you in your decision to avoid dynamic SQL, please read this document, appropriately entitled  "The Curse and Blessings of Dynamic SQL"

It's getting dark if nothing else.. and I'm heading for home now.. 'nuff work for this year now. See you next year

The 'proper' way of returning stuff from procedures, is to return errorcodes with return, and data with output parameters.

ALTER  PROCEDURE [usp_CopyJob] (@idJobSrc AS INT), @idJobNew int OUTPUT

AS

 ...

I guess that lies in the untold requirements..?

Since the poster extracted only the seconds 'counter' from the time, then you won't know the minutes. And since 59 + 1...

Just a note on very long IN lists.. If there are enough items in that IN clause you might encounter a stack overflow error. For very large lists, IN is inefficient...