FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Argh,

Ignore my other message...the xtypes are also used to map long char
types to their smaller brethen.  You can produce the corresponding types
by subtracting 128 (or clearing the high order bit). token.c does this for
VARCHAR and CHAR types.  This type has something different though.  It has
bit 7 (64) set instead.  So, 104 - 64 = 50 ... the old bit type, same as
the SYBNVARCHAR type. The gain with the other xtypes is they can be longer
than 255.  The gain here seems to be they are nullable.  So, the right
thing to do is add a type SYBBITN.  The problem is it doesn't seem to need
an extra byte for the length, so perhaps it is using a value of 0xff to
represent null on the wire?  I'll have to do some testing on this one.
It'll need some special handling anyway, it doesn't seem to be either what
we have traditionally called fixed and nullable types.

I've put some stuff in CVS that I think will allow querying of 0 or 1, but
null certainly wont work until we understand what it is doing.   

Cheers,

Brian

On Thu, 4 Jan 2001, Lowden, James K wrote:

> Here's another clue:
> 
> 1> select         cast (name as varchar(30)) as name
> 2>      , xtype
> 3>      , xusertype
> 4>      , usertype
> 5>      , allownulls
> 6>      , type
> 7> from systypes where name = 'bit'
> 8> go
>  name                           xtype xusertype usertype allownulls type
>  ------------------------------ ----- --------- -------- ---------- ----
>  bit                              104       104       16          1   50
> 
> Microsoft says: 
> xtype  is the "Physical storage type". 
> type is the "Physical storage data type". 
> 
> Another example of documentation that intentionally says nothing, I'm
> afraid.  
> 
> Microsoft added the xtype and xusertype columns to several system tables
> without explaining why (and the docs explicitly discourage even looking at
> the system tables).  It looks to me like they're sending the "xtype"
and the
> code is expecting a "type".  
> 
> "bit" is one of three datatypes whose type and xtype differ in the low-order
> byte.  The other two are "decimal" and "numeric".  About half the datatypes
> have the same value for type and xtype, and most of those that differ just
> have the high bit set on in the xtype (0xA7 vs. 0x27, for instance).  
> 
> My bet: you can add 104 as a fall-through case and treat it like a 50, as
> you suggest.  If you care about nulls, though, my other bet is there's no
> code to handle null bits.  It's worth a try.  
> 
> If you want to fix freetds, it appears you've turned over a rock and found
> something slimy.  If you want to get your code running, you should take
> James Cameron's advice and modify your query to CONVERT or CAST your bit
> field to something FreeTDS can handle.  
> 
> Hope this helps.
> 
> --jkl
> 
> -----Original Message-----
> From: Tim Uckun [mailto:tim AT diligence.com]
> Sent: January 3, 2001 12:23 PM
> To: TDS Development Group
> Subject: [freetds] Re: Odd problem round 2.
> 
> 
> Ok I started looking through the convert.c source code and in the function
> 
> tds_convert(..) there is a big switch statement switch(srctype). This is 
> getting a value of 104 for the BIT datatype. Unfortunately 104 is not 
> defined in tds.h as a valid type and therefore no conversion takes place.
> 
> There is a type called SYBBIT (type 50) and there is a function 
> called  tds_convert_bit. If the sybase bit fields are the same as ms-sql 
> bit fields then this is an easy fix (add the type MSSQLBIT and call the 
> same conversion function) if not then a new function will obviously need to 
> be written.
> 
> If these are bitmasks how would you know which bit was the on you are
> after??
> 
> Either way this is just from looking at a couple of files so I am sure 
> there are serious consequences to anything I might attempt with my feeble 
> understanding. Just thought I might throw in my two cents.
> 
> :wq
> Tim Uckun
> Due Diligence Inc. http://www.diligence.com/   Americas Background 
> Investigation Expert.
> If your company isn't doing background checks, maybe you haven't considered 
> the risks of a bad hire.
> 
> 
> ---
> You are currently subscribed to freetds as: [LowdenJK AT bernstein.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
> 
> 
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>