FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

On Fri, 26 Nov 1999 richard AT iguana.co.nz wrote:

> >From a message I posted to the PHP4b3 dev list:
> 
> ---
> 
> >From richard AT iguana.co.nz Fri Nov 26 10:21:58 1999
> Date: Fri, 26 Nov 1999 08:17:25 +1300 (NZDT)
> From: richard AT iguana.co.nz
> To: php4beta AT lists.php.net
> Subject: [PHP4BETA] php4b3 and freetds
> 
> Morning people. (well it is here, and a pretty one too). 
> 
> Opinions on freetds support under php4? the latest cvs will build with it,
> but for those who have tried it segfaults under certain circumstances.
> 
> I have tracked down the problem and "hacked" a fix in, and I *mean* hack,
> it sucks, but before I look at a real solution, I wanna know whether
> people are interested in supporting it. As far as I am aware, freetds is
> the only sybase-ct compatible library that will run on the latest debian
> and still talk to MS-SQL, so it might be a good move (I certainly hope
> so..:)
> 
> Essentially, after you get past the fact that freetds does an
> fprintf(stderr) where it shouldn't, the problem is that php4 calls
> ct_con_props(CS_GET,CS_CON_STATUS,..), and freetds doesn't support the
> status call (hence it tries to tell the user with an fprintf(stderr..) 
> which segfaults the program).
> 
> As far as I can see, its a missing feature in freetds, which should really
> be recitified, I can look at doing that, but is there a decent number of
> people who are likely to be in this situation?
> 
> ---
> 
> The response from the PHP4 developers is that they definitely want freetds
> in there. Any chance of an implementation of GET CS_CON_STATUS ? I'd love
> it :)
> 
> If someone just wants to gimme a quick rundown of how exactly I determine
> whether the socket is connected/dead (ie: do I just stat, or is there more
> to it?) I can add the actual code in no problems, I just wasn't sure
> whether a connection being CS_CONSTAT_DEAD was TCP level dead or database
> level dead.
> 
> Richard.
> 

According to the doc, CS_CONSTAT_DEAD bit is set if "errors have made it
unusable or if an application's client message callback routine returns
CS_FAIL" and then goes on to say that if you are processing results you
can attempt to issue a ct_cancel() and resume.

The second reason is easy enough to handle but the first one is a bit
vague, but since it requires calling ct_close() it would appear that the
socket is still open but unusable. It also mentions only "client
messages", which are messages generated internally from ctlib, it seems to
have nothing to do with the connection per se.  Since there is currently a
grand total of 1 client message (results pending) there is not much to
worry about. 

It appears that checking tds->s will be good enough to determine the
status of the CS_CONSTAT_CONNECTED bit.

Brian