FreeTDS Development Group

["Thompson, Bill D (London)" <bill_d_thompson AT ml.com>]

Hey James,

I think you're on the right track.
IIRC, A TDS 5.0 bcp "row" reflects the physical layout of a row in the
sybase database.

The Sybase manual states (in different places) that either 7 or 8 "bit"
columns can be stored in a single byte in the database.

I can't find anything on how precisely this is done...questions I would
be asking are:

1) do bit columns have to be declared contiguously in a table definition
?
2) If not, where in the record does the single byte reside - at the
position of the first declared bit column ?

The manual says:

"The status column in the syscolumns system table indicates the unique
offset position for bit datatype columns"

so I guess some experimentation with different table definitions might
answer these questions.

HTH,

Bill




-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: 08 December 2006 04:10
To: TDS Development Group
Subject: [freetds] bcp currently broken for BIT type in TDS 5.0


Trying to bcp in to a table with BIT fields on Adaptive Server
Enterprise
12.5.1 leads to unhappy results.  I don't know yet how long this has
been
broken:

1> exec sp_layout bittypes
2> go
 ColumnName Type                      Length      Nulls
 ---------- ------------------------- ----------- -----
 variable   bit                                 1   N  
 allownulls bit                                 1   N  

$ cat bittypes.txt 
0       1

$ ./freebcp FreeTDS..bittypes in bittypes.txt ...

Starting copy...
Msg 4837, Level 16, State 3
Server 'test', Line 1
        Bad row data received from the client while bulk copying into
object 1228528379 in database 4. Received a row of length 4 whilst
maximum
or expected row length is 3.

Can someone easily tell me what the packet should look like?  From the
log:

bcp.c:1364:Normal end-of-file reached while loading bcp data file.
net.c:724:Sending packet
0000 07 01 00 0e 00 00 00 00-04 00 00 00 00 01       |........ ......|

I'm not sure how to decipher that, but it looks like it announces 4
bytes:

04 00   size 
00 00   ??
00      1st bit
01      2nd bit


This is what the received row looked like when it was taken from the
server:

net.c:579:Received packet
0000 61 42 00 00 00 02 00 00-00 00 08 62 69 74 74 79 |aB...... ...bitty|
0010 70 65 73 08 76 61 72 69-61 62 6c 65 10 00 00 00 |pes.vari able....|
0020 10 00 00 00 32 00 00 00-00 08 62 69 74 74 79 70 |....2... ..bittyp|
0030 65 73 0a 61 6c 6c 6f 77-6e 75 6c 6c 73 10 00 00 |es.allow nulls...|
0040 00 10 00 00 00 32 00 ae-02 00 00 00 d1 00 01 fd |.....2.. ........|
0050 10 00 02 00 01 00 00 00-                        |........|

The row packet starts at 004C and breaks down as:

d1      TDS_ROW
00      1st bit (0)
01      2nd bit (1)

It's getting late, so I'm going to stop thinking about this and hope
someone knows the answer or can trace it for me.  I'm guessing Sybase
wants us to shoehorn two bit in one byte.  Not unreasonable....

Many thanks.  

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------