FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

> From: Lowden, James K 
> Sent: Friday, December 19, 2003 11:01 AM
> To: 'FreeTDS Development Group'
> Subject: RE: [freetds] Status: bcp
> 
> 
> > From: Thompson, Bill D (London) [mailto:bill_d_thompson AT ml.com]
> > Sent: December 19, 2003 8:11 AM
> > 
> > 1) Sybase open client does NOT put out the message. I
> > recompiled the new test program against Sybase to prove it.
> 
> Based on the db-lib documentation, I don't see how they 
> could.  AFAIK, a db-lib handler can't return anything like 
> "OK, fine, go ahead", so it can't be passed mere 
> informational messages.  

Huh?  There's an entire class of informational messages with severity class
EXINFO.  Are we talking about the same thing?

It's perfectly legitimate for an error handler to return INT_CANCEL and
expect the program to continue doing what it was doing before.  The
semantics are strange, but it's the correct behavior.

> I have a db-lib manual from 1986.  It lists 55 possible 
> errors, all SYBE* types.  No informational messages.  My 
> theory is that the SYBI* messages you found document messages 
> that can be emitted by Sybase's utilities.  
> 
> Nick says he *depends* on that message.  I don't see how.  I 
> really think we should remove it.  

I don't understand why you would want to remove it.  It would make more
sense to find and fix the real underlying cause of the problem you're
experiencing.

> > 2) where did the message come from ? searching through my
> > memory banks, I
> > remember going through sybase's sybdb.h for any bcp related 
> > error messages ... and put it into my code where it seemed 
> to belong.
> 
> I thought that might be what happened.  It's good we know the 
> basis, in case we find other such anomalies.  
> 
> >      I'm guessing therefore that some of our code is now more
> > sensitive to the TDS_DEAD state than it used to be.
> 
> Right.  We're working toward intelligent reporting of 
> terminated connections, instead of just blindly stumbling on 
> until we dereference a null pointer.  Seems more elegant, somehow.  

I haven't looked at these changes,  but if you're blindly killing the
connection whenever an informational message is sent from dblib to the
client, that's even worse than just stumbling on when a real error has
occurred.

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.