On Tuesday 02 May 2006 00:53, Bojan Smojver wrote: > I'm guessing foo_clearerror() is a database specific function for > clearing errors, if such a beast exists.
Yep. > If not, user gets back > APR_ENOTIMPL status and the whole transaction must be rolled back. Erm, no. It it doesn't exist, that reduces to resetting trans->errnum. > This would obviously need to be called every time an error code is > returned by query/select, right? If the application wants to handle the error (other than in the default manner) then yes. > Still a little bit unclear on the function of > APR_DBD_TRANSACTION_DEFAULT here. Given that the errors need to be > cleared explicitly anyway (or at least that's how I read it), having > one commit mode should be sufficient (i.e. if the errors weren't > cleared by using APR_DBD_TRANSACTION_CLEARERR, commit won't work > anyway). Well, it's something we can initialise and reset to. It'll just give current behaviour. Could be relevant in cases like oracle, where (according to your earlier post) it will commit even when there's an error, so that gives us three behaviours that are clearly distinct. -- Nick Kew
