On 22/02/2010 20:46, pr wrote:
--- On Mon, 2/22/10, Martin J. Evans<[email protected]>  wrote:

From: Martin J. Evans<[email protected]>
Subject: Re: Error during SQL Server restore fails to propagate back to DBI 
client on Windows
To: "pr"<[email protected]>
Cc: [email protected]
Date: Monday, February 22, 2010, 7:35 PM
On 21/02/2010 17:37, pr wrote:

Something strange is going on. I seem to be getting mails
from you like the one dated above (which I received in the
last hour) a day later. This is making it impossible to keep
track of where we are. Perhaps you could read the last email
I sent 2 hours ago around 5pm UK time 22-feb-2010 and start
again from there. Also the content is now almost impossible
to follow so if you have points to come back on please trim
the old content down to my last posting and any comments you
have. I could address comments in your last posting but I
think I already did most of that 2 hours ago.

Martin
--
Hi Martin,

Thank you again for your time-- I really do appreciate it.

I understand (at least at some level) why odbc_exec_direct needs to be set to 
true in order to successfully issue a restore database.

My lingering concern is: suppose odbc_exec_direct is (incorrectly) set to false 
for this.  Is it possible to trap this error on the client, so that we know it 
did not complete successfully?

The reason for the concern: it seems best to be able to trap any error without 
knowing whether odbc_exec_direct is set appropriately, since otherwise every 
statement (especially administrative commands) would require testing after 
every SQL Server patch to ensure any errors would be caught.

I can“t seem to catch the error client side when odbc_exec_direct is false.  Is 
this possible?

Thanks again,
I think I've already answered this. I don't think you can do what you want. You can of course, set odbc_exec_direct on the connection handle and I think it will be inherited by all statement handles. However, I've not tested this and I'm unsure if this would have any negative effects elsewhere.

Martin

--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Reply via email to