We have a 5-6 year old SQL ODBC wrapper DLL for ODBC 2.0 basically wrapping
ODBC 2.0 functions to easier usage in our application.

It works for many years, no complaints, no leaks reported etc. But now that
I am revisiting it to add some new functionality to it, I am finding that
under VS 6.0 debugger, it is deadlocking when the application ends.

I zoomed on the problem and it seems that I have a problem when it calls:

SQLFreeHandle(SQL_HANDLE_DBC, hdbc);

If I comment this out, its find.

Now normally, I would think there was a corrupting issue. But I just finish
putting our applet under a high stress memory heap managements tracing and
nothing is showing up.

So I resorted to MSDN docs and I think there might be some here that might
help related to ODBC 3.0 drivers?

It says that if use:

SQLFreeHandle(SQL_HANDLE_DBC, hdbc);

Internally, it will wrap this to:

switch (HandleType) {
case SQL_HANDLE_ENV: return (SQLFreeEnv(Handle));
case SQL_HANDLE_DBC: return (SQLFreeConnect(Handle));
case SQL_HANDLE_STMT: return (SQLFreeStmt(Handle, SQL_DROP));
default:
}

It seems to me that unless a SQLConnect() is successful, that you don't need
to calls SQLFreeConnect() directly?

In my code, I have what basically follows all the MSDN examples following
the Z-order for allocation and freeing handles:

Example (with error statements for readability)

SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);
SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0);
SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
SQLConnect(hdbc,....);
SQLDisconnect(hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc); << see below
SQLFreeHandle(SQL_HANDLE_ENV, henv);

Unless I'm reading this wrong, is that SQLFreeHandle(SQL_HANDLE_DBC, hdbc)
necessary?

Anyway, any tips or experience reading a SQLFreeHandle() deadlock would be
appreciated. A good search on "SQLFreeHandle Deadlock" shows that other
applications has the same problem.

Thanks

---
HLS