FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: February 13, 2003 11:09 AM
> 
> I found that our dbresults() processing was behaving slightly 
> diffently from
> Sybase's, and have written a patch to remedy this situation
> 
> The patch is relatively small and affects dblib.c and sybdb.h

Thanks, Bill.  Committed.  

I made minor changes around line 1040.  The procedure has to return
something, and I think it's better to use the last switch for finding
successful conditions, and just to drop out of it if you don't find what
you're looking for.  

As a technical matter, in the .h, I think we should rely more on enumerated
types than sequential #define statements.  I saw that you were extending a
pattern, but I have half a mind to rip through the headers converting
everything to possible to enums. 

That reminds me of a gotcha I noticed last night.  There are times that we
use #define or enum for things that Sybase defines as a bitmask against a
TDS field.  The protocol defines a size for the field, of course, typically
16 bits.  I believe our mask should reflect their definition precisely, vis:

#define TDS_DONE_COUNT ((TDS_SMALLINT) 0x0010)
or
const static TDS_USMALLINT TDS_DONE_COUNT = 0x0010;

rather than an enum.  Besides being slightly inefficient, widening the TDS
field to match the 32- or 64-bit enum distorts the meaning.  Anyone else
have an opinion?  

--jkl


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.