freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "'TDS Development Group'" <freetds AT franklin.oit.unc.edu>
- Subject: Re: Odd problem round 2.
- Date: Thu, 4 Jan 2001 11:03:39 -0500
Title: RE: [freetds] Re: Odd problem round 2.
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')
-
Odd problem round 2.,
Tim Uckun, 01/02/2001
- <Possible follow-up(s)>
- Re: Odd problem round 2., James Cameron, 01/02/2001
- Re: Odd problem round 2., Tim Uckun, 01/02/2001
- Re: Odd problem round 2., Michael Peppler, 01/02/2001
- Re: Odd problem round 2., James Cameron, 01/02/2001
- Re: Odd problem round 2., D. J. Hagberg, 01/02/2001
- Re: Odd problem round 2., Tim Uckun, 01/03/2001
- Re: Odd problem round 2., James K. Lowden, 01/03/2001
- Re: Odd problem round 2., Tim Uckun, 01/03/2001
- Re: Odd problem round 2., Lowden, James K, 01/04/2001
- Re: Odd problem round 2., Brian Bruns, 01/21/2001
- Re: Odd problem round 2., Brian Bruns, 01/21/2001
Archive powered by MHonArc 2.6.24.