[freetds] 0.64 status and coverage
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Fri Jul 15 03:48:14 EDT 2005
> On Thu, 14 Jul 2005, Frediano Ziglio wrote:
> > I know however it's a nice feature to have and easy to implement.
> > In early days there where an executable linked to some few libraries
> > (like libc) but nowadays in context like
> > <- PHP <- php_mssql.so <-
> > httpd (Apache) <- Python <- ???.so <- libdblib.so
> > <- mod_perl <- DBD::DBLib <-
> > is difficult to define who should call dbexit... you end up in
> > situations where the better way is to call only dbinit... I
> got the same
> > problem with socket and windows. Under windows you have to
> > socket library with WSAStartup, use sockets and then you should call
> > WSACleanup. However after WSACleanup you cannot call any
> socket API. In
> > 3 cases (OCX used in an ASP page, ISAPI and an extended
> store procedure
> > in mssql) I decided to NOT call WSACleanup to prevent main program
> > (respectively IIS, IIS and mssql) to stop working correctly
> (in IIS case
> > I decided to not call WSAStartup too...). Now in FreeTDS
> you can call
> > safety dbinit/dbexit, just call dbinit and dbexit once.
> FWIW WSAStartup/Cleanup and most routines that I know of that
> behave in
> the same way use internal reference counts to prevent
> problems like the
> above from occuring. You just need to make sure that you
> call init the
> same number of times you can cleanup. Only the last call to cleanup
> actually does anything.
> Have Fun!
At the time I wrote those application WSACleanup didn't work so.
dbinit/dbexit now should work as you described.
More information about the FreeTDS