FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

I'm always surprised when I can corrupt a table at will.  I'm not quite
sure of the details yet, but something in our bcp for TDS 5.0 is currently
able to load data into a table that can't be selected back out.  

After loading the table with my test program, neither sqsh nor Sybase's
isql can select the row.  The TDSDUMP and tcpdump records agree, and
Sybase's Ribo tool also cannot decode the stream.  

1> select * from T
2> go
 t           r                    s                             
 ----------- -------------------- ------------------------------
           1             1.100000 one                           
           2             2.200000 two                           
        NULL             3.300000 three                         
           4             4.400000 four                          
           0             5.500000 five                          
           6             2.075256                               
Open Client Message
Layer 0, Origin 0, Severity 78, Number 52
Unknown marker

And here's the last bit of the packet:

        -- the "five" row
d1 
04      00 00 00 00 
04      00 00 b0 40 
04      66 69 76 65 

        -- the "six" row
d1 
04      06 00 00 00 
03      00 d1 04 
07      00 00 00 04 66 66 f6 

40 01 30 ????
^^  FreeTDS reports 0x40 as the "unknown marker"

        -- the "eight" row
d1      
04      08 00 00 00 
04      cd cc 0c 41 
05      65 69 67 68 74 

fd 10 00 02 00 08 00 00 00

The problem appears to be that the "six" and "seven" rows are actually
missing some bytes:

        -- the "six" row
d1 
04      06 00 00 00 
03      00 
        -- oops! 

d1 
04      07 00 00 00 
04      66 66 f6 40 
01      30
        -- more oops: the data should be 'seven'

Here's a clue:

[25] alex.FreeTDS.1> sp_layout T
[25] alex.FreeTDS.2> go
 ColumnName Type                      Length      Nulls
 ---------- ------------------------- ----------- -----
 t          int                                 4   Y  
 r          real                                4   Y  
 s          varchar                            30   N  
                                                   ^^^ not NULL! 


1> select t, coalesce(s, "s can't be null") from T where t = 6 
2> go
 t                                         
 ----------- ------------------------------
           6 s can't be null               

Apparently, we can load a NULL into a non-NULL column.  There's logic in
bcp.c to prevent that, and you'd think think the server would object!  But
it doesn't, and there's no appropriate message in master..sysmessages, so
it looks like it's the client's obligation to get right.  

Back to the rockpile.  

--jkl