Greetings, I am chasing some "leaked" ODBC statement handles.
I see that ODatabaseMetaDataResultSet.cxx takes care *not* to free a statement handle which has not been subjected to one of 13 member functions with names starting "open...". Questions arising ... (1) Why should this protection be necessary, does anyone know offhand? It is conceivable that some called function takes responsibility for freeing the statement handle. But I have looked through the present class for functions which reference the statement handle without setting the flag to free the handle, and I see only function names (I have not looked farther than the names) that make such transfer of responsibility sound unlikely: 10 functions with names like "get<sometype>", 6 positioning functions (first, last, absolute, relative, previous, and next), and "cancel" (which, IIRC wraps SQLCancel). (2) Does anyone know offhand of a good reason for a client of the present class to instantiate it without apparently doing anything with the statement? The particular leaked statement handles that I see appear in the ODBC log file only as return values from SQLAllocHandle. (It is just possible that the failure to do anything with the handle is related to the funny query results that I was looking at when I noticed the leaked handles.) (3) Would it be good to report statement handles which "disposing", as currently written, does not free? Is there a better place to do this than "disposing"? I imagine showing a few words and the handle itself. Is there something else which would be useful and easy to do? Thank you, all, for your attention. Terry. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice