[freetds] bug/change in behavior in handling null text columns

James K. Lowden jklowden at freetds.org
Thu May 24 13:23:28 EDT 2007


John Mund wrote:
>    There is a difference between .63 and .64 versions on how null text 
> columns are handled.  I believe it is a bug.    When you have a text 
> column that previously had a value and then was set to null, 
> freetds-0.64 doesn't appear to treat it as null, but rather some kind of
> 
> zero length string.  This causes problems downstream (php blows up). 
> Version .63 correctly treated it as null.
...
> To reproduce in tsql
> 1> create table #t (t1 text null, t2 text null)
> 2> insert #t (t1) select "a"
> 3> select * from #t
> 4> go
> t1      t2
> a       NULL
> 1>  update #t set t1=null
> 2> select * from #t
> 3> go
> t1      t2
>        NULL
> 
> The value for t1 is a blank, but not a null.  I believe this should be a
> 
> NULL.  The same sql to same databases (from Intel/FreeBSD 5.4) using 
> freetds-0.63 results in:
> t1      t2
> NULL    NULL

This is fixed in the current snapshot:

$ cat /tmp/nulltest.sql
create table #t (t1 text NULL, t2 text NULL)
insert #t(t1) values ('a')
select * from #t
update #t set t1 = NULL
select * from #t
go

$ tsql -S$S -U$U -P$P < /tmp/nulltest.sql
locale is "C"
locale charset is "646"
1> 2> 3> 4> 5> 6> $ vi /tmp/nulltest.sql
$ tsql -S$S -U$U -P$P < /tmp/nulltest.sql
locale is "C"
locale charset is "646"
1> 2> 3> 4> 5> 6> t1    t2
a       NULL
t1      t2
NULL    NULL

$ bsqldb -S$S -U$U -P$P < /tmp/nulltest.sql
@@rowcount not available
t1  t2
--  --
a   NU
1 rows affected
t1  t2
--  --
NU  NU
1 rows affected

$ sqsh -m vert  -w 10000 -S$S < /tmp/nulltest.sql | cut -b-60
t1: a
t2: NULL
 
(1 row affected)
t1: NULL
t2: NULL
 
(1 row affected)

This is how we know when it's time to issue a new release: when the best
advice is "use the current snapshot."  :-)

--jkl



More information about the FreeTDS mailing list