--- 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, -rt
