[unixODBC-support] Why does SQLDisconnect trigger a call to SQLFreeHandle(SQL_HANDLE_ENV) ?
andy.grove at codefutures.com
Fri Jun 24 13:48:37 BST 2011
Thanks for the speedy response. That makes sense. The main problem I had was that in my ODBC driver implementation I was assuming that the SQL_HANDLE_ENV would stay around and I was keeping some critical state there. Now that I understand this better I can see that this wasn't the correct design.
Thanks again for your help with this.
On Jun 24, 2011, at 2:34 AM, Nick Gorham wrote:
> On 24/06/11 05:05, Andy Grove wrote:
>> I'm using unixODBC 2.3.0 with a custom ODBC driver that I have developed and I've encountered a confusing issue in one customer environment where it appears that unixODBC is calling SQLFreeHandle(SQL_HANDLE_ENV) immediately after a call to SQLDisconnect() even though the application hasn't requested that the environment be freed.
>> I've been debugging this for several hours and can't see any other possibility but this doesn't seem like correct behavior. I'd appreciate any suggestions/feedback on this. Is it possible that unixODBC would be doing this? The call to SQLDisconnect would bring the connection count down to zero if that is any help. The customer's environment is a Python/Django application deployed in the fastcgi application server.
>> I can provided detailed debug logs as well if that helps.
> Yep, just checked the code. Once the count of connections to a driver reduces to zero that driver is disconnected. I don't see any other action the driver manager could take, hold onto the driver (and possibly 100 others) just in case the app decides to use it again. If thats a problem for your driver then you can disable it by enabling pooling into the driver manager.
> unixODBC-support mailing list
> unixODBC-support at mailman.unixodbc.org
More information about the unixODBC-support