Terrence Enger wrote:
Hmm. Is my question really of no interest? Or did I just time it badly with respect to the big conference?
Hi Terry, I guess you'll get better answers on the dev list -
On Fri, 2011-10-14 at 09:50 -0400, Terrence Enger wrote:I notice that at least some calls from Base to ODBC routines fail to check the return code, and I wonder what we should be doing. The particular situation that caught my interest arises this way ... (*) Base allocates and uses a connection handle. (*) Upon closing the database, the code tries to free that handle without calling SQLDisconnect. SQLFreeHandle returns -1 (SQL_ERROR), and sets sqlstate HY010 (function sequence error). (*) The statistics tab of ODBCConfig (part of unixODBC on ubuntu-natty) shows that one connection is allocated. A call to SQLDisconnect before the call to SQLFreeHandle within OConnection::~OConnection() has worked once(!) without causing obvious difficulties.
Great to see you've investigated even deeper - could you pour this into a patch & mail the dev list, with a proper [PATCH] in the subject?
( Aside to the kind people who were discussing automated testing with me last week: I anticipate that leaked connection handles could cause difficulty in the context of automated tests, either from opening and closing many databases within one instance of soffice.bin, or from a driver manager less generous with handles than the one I am using here now. See, folks, I have not been ignoring you just for the sake of ignoring you <grin />. ) What else should the code generally do? Should we continue to ignore errors? (After all, I only noticed the particular situation because I am nasty person who is just looking for trouble <grin />.) Should we be asserting adequately good return values? We could collect diagnostic information, if we knew how to get the attention of somebody who cares. Can we even think about throwing exceptions from a low-level wrapper around the ODBC routine?
Cheers, -- Thorsten
Attachment:
pgpqvIF7l3hte.pgp
Description: PGP signature