FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

On Tue, 18 Jun 2002 21:17:45 -0300, "Andre Costa" <brblueser AT uol.com.br>
wrote:

> [config info: FreeTDS 0.53 compiled with gcc-3.1 on Linux RH 7.1, PHP
> 4.0.6, MS-SQL Sever 7.0 on Win2000, protocol version 7.0]
> 
> my queries are returning some bogus '\0' on text fields. This is, of
> course, causing havoc on my PHP program...

Hmmm.  Why "of course"?

> For example, a result that should come as
> 
> Academias
> 
> comes as
> 
> Academias\000\000\000\000\000\000\000\000\000

Andre, 

I don't know PHP semantics, but I think this is a binding question. 
That is, FreeTDS receives a field from the server.  Then it has to
hand it to a C program, which wants it in a C variable.  The C program
provides a buffer to FreeTDS, and calls one of the API's functions to
move the raw TDS data into the buffer.  When it does, it tells
FreeTDS what to do with the field and how (and if) to terminate it.  

Here's a snippet from the dbbind doc:

The available representations for character data are shown below. They 
differ according to whether the data is blank-padded or null-terminated:
Vartype          Program type    Padding    Terminator
CHARBIND         DBCHAR          blanks     none
STRINGBIND       DBCHAR          blanks     \0
NTBSTRINGBIND    DBCHAR          none       \0
VARYCHARBIND     DBVARYCHAR      none       none

IOW, depending on how PHP chooses to ask FreeTDS to convert the
stream, you might or might not get a terminating null.  

The function (dbbind, whatever) also returns a length.  Like any
partially used buffer, the data beyond that length are
undefined.  

I'm sorry if that's all terribly obvious.  If you could explain why
you *care* :) about the data beyond the end of your strings, perhaps
I could be more helpful?  

Regards, 

--jkl