leaked ODBC statement handles

[Terrence Enger]

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.