FreeTDS Development Group

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

I think fixed our null handling in bcp.c.  If you did this:

1> create table t (t varchar(9) null)
2> go
1> insert t values ('a')
2> insert t values (NULL)
3> select * from t
4> go
(1 row affected)
(1 row affected)
 t
 ---------
 a
 NULL

freebcp gave you two 'a' rows, and no nulls:  

$  freebcp testdb..t out tt -c -S spquant -U $U -P $P
Starting copy...
firstrow = 0 row_of_query = 2 rows written 2
2 rows copied.

$ cat tt
a
a

Ugh.  

token.c::tds_get_data() correctly calls tds_set_null().  The data structure
at that point is weird: the "current_row" is a char*, but it actually
comprises 4 bytes of flags followed by N bytes of true data.   In
bcp.c::_exec_bcp_out(), the null status of the data was ignored, and the
function copied (in my case) one byte of stale data to the output file.  

Now it instead calls tds_get_null() to decide whether or not to write
anything.  

This might be only a partial solution.  I don't know if bcp bindings should
honor dbsetnull().  The documentation says dbsetnull() affects dbbind() and
dbconvert(); nothing about bcp_bind().  

--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.