FreeTDS Development Group

[Paul Robinson <paul.robinson AT groupbc.com>]

Frediano Ziglio wrote:
> Il giorno mar, 02/08/2005 alle 13.13 +0100, Paul Robinson ha scritto:
>
> > Thanks Bill.
> >
> > BOL?? - I don't know what this is.
> > Presumably there is some documentation somewhere that you are referring 
> > to for the dblib API - I've been working on this issue we found (in PHP 
> > really rather than FreeTDS) and this seemed the simplest way to solve 
> > it. I'm not familiar with the API that is implemented at all. 
> > Documentation pointers are always appreciated.
> >
> > Even if this is the case that wouldn't _necessarily_ give a way of 
> > determining the difference between and empty VARCHAR string and a NULL 
> > value - would it?
>
> Original SQL Server could not distinguish empty string from NULL. Or
> better... empty strings was stored as a single space ' ' while NULL was
> stored as... empty string (''). dblib is the original library so len ==
> 0 always means NULL. I don't know however if using recent protocol dblib
> return ' ' for empty database strings...
> Fixed in CVS (0.63). Already fixed time ago in 0.64 (CVS HEAD) as a side
> offset of null handling rewriting. Attached post 0.63 patch.

Thanks for that extra info.
I'm now running with a lightly modified PHP 5.0.4 that is testing for a 
zero returned from dbretlen rather than my hacked on dbretisnull.
I've also included CVS version 1.32.2.7 of dblib/rpc.c in my FreeTDS 
build which I found was required to handle SQLTEXT fields successfully.

This seems to be working fine right now.

I'll be hopefully closing off the two PHP bugs I opened with appropriate 
patch submissions:
http://bugs.php.net/bug.php?id=33965&edit=2
http://bugs.php.net/bug.php?id=33963&edit=2

Thanks for the help and suggestions.

        Paul
--
Paul Robinson
Systems Manager
Business Collaborator Ltd
WWW: http://www.groupbc.com