On 22/02/2010 20:46, pr wrote: > --- On Mon, 2/22/10, Martin J. Evans<martin.evans@easysoft.com> wrote: > > >> From: Martin J. Evans<martin.evans@easysoft.com> >> Subject: Re: Error during SQL Server restore fails to propagate back to DBI client on Windows >> To: "pr"<rtkenzie@yahoo.com> >> Cc: dbi-users@perl.org >> 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.comThread Previous