FreeTDS Development Group

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

tds_process_default_tokens will return TDS_FAIL if that happens so it's 
better to check the return code (this should propagate up through the API 
to the client, but I'm not sure if it does in all cases or not.  Anyway the 
best thing would be to check the return code from dbnextrow() etc... for a 
FAIL error.  At that point DBDEAD() should be valid.  I'll happily accept 
patches to improve error handling :-)

Brian

On 01/20/00, ""Geoff Winkless" <geoff AT farmline.com>" wrote:
> Ok... so I've got a connection open to the server. It's a persistent
> connection because that makes it a -load- faster and this thing is providing
> all the authentication for an Email server (this has been running for some
> months).
> 
> Basically you have robots that read from an IPC message queue and
> authenticate the username/password/domain triad that comes in the message.
> This all works and is ridiculously fast...
> 
> The problem is that when the SQL server crashes and reboots (it's NT,
> unfortunately, so this has happened a couple of times now...) there doesn't
> seem to be an easy way of dblib/freetds telling that it's died. I've
> reproduced this by setting up a second server and simply killing the server
> while the connection is held open, and all that happens is I get
> 
> Unknown marker: 0!!
> Unknown marker: 0!!
> 
> from the robot.
> 
> No errors, no messages.
> 
> Where would I start implimenting some code to catch this??? I've asked
> before if there were a way of checking the validity of a connection but
> DBDEAD only checks to see if the connection is not NULL... and anyway the
> problem could still occur in between checking a connection and actually
> running dbsqlexec.
> 
> I suppose I could check for the 0 marker in tds_process_default_tokens and
> raise an error if so but I'm not sure
> 
> a) if this is the correct way to go about things or
> b) if any other state would produce a marker 0.
> 
> If no-one suggests anything better I guess this is what I'll do...
> 
> Any hints appreciated.
> 
> Geoff