FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> James K. Lowden wrote:
> > net.c::tds_select().  
> > 
> > It's not called by anything yet, so it can't do any harm.  
> 
> No longer.  net.c has been redone in terms of tds_select.  
> Cancel messages
> are now subject to the same timeouts as queries.  
> tds_goodwrite looks a
> lot like tds_goodread.  Timeout conditions invoke the client library's
> error handler.  
> 

Looking at tds_goodread/tds_goodwrite it seems that moving tdserror call
in tds_select would help reducing code.

> All I know for sure is that all but one unit test passed for 
> ct-lib and
> db-lib.  ct-lib's "connect_fail" test failed.  I'm not 
> surprised, because
> I didn't modify the ct-lib error handling yet.  
> 
> We have tests that cancel queries, but I don't think we have 
> anything that
> specifically tests timeout handling.  So I think tds_select() 
> works when
> everything's OK.  I'm not yet convinced it works with something goes
> wrong.  
> 
> I didn't compile the ODBC driver.  I'm not set up for it at 
> the moment. 
> Do we have an ODBC timeout unit test?   
> 

Yes, odbc contains a timeout test.

> I don't have a way to test tds7_get_instance_port(), either.  I don't
> think it should call tdserror because TDSETIME isn't appropriate and
> neither is anything else.  It's not subject to a login 
> timeout or a query
> timeout.  Probably the code should (and does) silently try a 
> few times and
> return failure if it doesn't get an answer.  Ultimately that becomes a
> "could not connect" message.  
> 

if you don't know the port to connect this become (correctly) a connect
problem. But looking at login.c I see no tdserror call if port is
invalid

  if (!IS_TDS50(tds) && !tds_dstr_isempty(&connection->instance_name))
    connection->port =
tds7_get_instance_port(tds_dstr_cstr(&connection->ip_addr),
tds_dstr_cstr(&connection->instance_name));

  if (connection->port < 1) {
    tdsdump_log(TDS_DBG_ERROR, "invalid port number\n");
    return TDS_FAIL;
  }

> I'll look at ct-lib next, to fix up its error-handler 
> interface to libtds.
>  Then I'll work on a unit test or two.  I'm hoping to have 
> that done in a
> few days.  Then I hope folks will start to use the new snapshots and
> provide feedback.  Patches welcome too!  
> 
> Many thanks to Frediano and Peter Deacon for their advice.  
> 

Trying to fix odbc.c I noted that we don't make any difference between
msg_handler and err_handler however in libTDS they are handled in a very
different way (msg_handler result is ignored). Another problem (at least
in ODBC) is that we copy server name from first handler call however for
client messages server is always "OpenClient".

freddy77