[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