--- On Mon, 2/22/10, Martin J. Evans <[email protected]> wrote: > <huger amounts snipped> > > Yes, it does work for me when {odbc_exec_direct} is > set to true. I also understand your explanation of why > this is the correct way to do things. > > > > > You need to set odbc_exec_direct - sorry if this prove > inconvenient for > you but there is no other way for DBD::ODBC to know you > need to do this. > > > The real concern here is why error 3224 seems > untrappable if this restore is done with {odbc_exec_direct} > is set to false. I cannot see how to trap this error > at all. > > > > > I don't think there is a way to do this. I replicated your > situation in > C via ODBC and get the same issue. You could perhaps talk > to Microsoft > but I doubt it will get you anywhere. > > > Is it possible to (incorrectly) set odbc_exec_direct > to false, issue the database restore, and trap error 3224 in > perl? > > > > > I don't believe so via Perl and DBD::ODBC or even directly > via the ODBC API. > > > In fairness, perhaps due to my inability to follow where > you were going > I've taken a bit too long to get to the gist of your issues > and it has > arguably highlighted an issue in SQLMoreResults not calling > set_err in > DBI. I always try to help although not always > successfully. >
Thank you very much, Martin! Your explanation has been tremendously helpful. It's really appreciated! If I'm not out of turn, I find this an interesting corner case. Maybe it merits putting a brief description+caveat in a later version of the DBD::ODBC docs? Once again, thank you for all of your time and help! -rt
