Skip to Content.
Sympa Menu

freetds - Re: PHP's mssql_fetch_row inserting '\0' on strings?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Andre Costa <brblueser AT uol.com.br>
  • To: "TDS Development Group" <freetds AT franklin.metalab.unc.edu>
  • Cc: jklowden AT speakeasy.org
  • Subject: Re: PHP's mssql_fetch_row inserting '\0' on strings?
  • Date: Wed, 19 Jun 2002 14:41:09 -0300


Hi James, hope all is fine.

It's amazing how you still give such detailed feedback about user posts
while working so hard on FreeTDS as you've been doing. All I can say is
"thank you very much" ;)

Now that I took some rest I am in better shape, so I *should* be able to
engage a more interesting conversation. I will try ;)

On Tue, 18 Jun 2002 21:57:02 -0400
"James K. Lowden" <jklowden AT speakeasy.org> wrote:

> > my queries are returning some bogus '\0' on text fields. This is, of
> > course, causing havoc on my PHP program...
>
> Hmmm. Why "of course"?

My previous tests with FreeTDS were returning "well-formed" strings for my
queries (i.e. no embedded \0s). This means that I did not have to do any
post-processing and could use them directly (these strings are used "as
is" as attributes to XML data).

The embedded \0s are going straight to the XML output, and the client
program is choking on them. On this specific case, they are not supposed
to be there. So, this is what I (dramatically, I admit ;) ) referred to as
"havoc" ;)

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

Thank you for the explanation. It is strange because what I've been having
doesn't seem to fit any of the descriptions above (the strings are not
padded, their size varies). Perhaps, as I said, the first \0 correctly
marks the end of each string. However, why PHP still considers chars
beyond it is what is puzzling me (remember that 4.2 behaves differently --
which is not a surprise at all, just additional info).

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

Mmmh... this could be it. It could be that this function is returning a \0
marker *and* a length, and they don't match. Anyway, this could be PHP's
fault, since I am not using the latest version. I will see if I manage to
find some time to try a later version.

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

No need to be sorry, you're trying to get the picture. As I said, it was a
pitiful report after all ;)

The bottom line is: I think I can find a workaround for embedded zeros, if
it turns to be unavoidable. But, to be honest, I still don't understand
why such strings are being returned by TDS 7.0 instead of "plain" strings
returned by TDS 4.2 for the same command (mssql_fetch_row) and the same
set of data.

BTW: sqsh also return the "right" data (no \0s).

I will see if I can do more tests here. I will post my findings. In the
meantime, any ideas will be welcome.

Thanks for the help.

Best,

Andre




Archive powered by MHonArc 2.6.24.

Top of Page