FreeTDS Development Group

["Michael Sims" <michaels AT crye-leike.com>]

Hi, thanks for responding...

Daniel Fazekas wrote:
> On Apr 1, 2004, at 1:37, Michael Sims wrote:
>
> While the change in behavior is certainly noteworthy, and hopefully
> the developers will have an idea, if I read your description right,
> it's not a serious problem and you shouldn't be too concerned.

I have to respectfully disagree with that (see below).

> All PHP *_query functions are supposed to have three possible results:
>
> 1. bool false if the query failed
> 2. bool true if the query succeeded and that's all the information
> there is (for example a successful UPDATE or DELETE)
> 3. a result resource

That's true, but in the case that the query is a SELECT, or functionally
equivalent (a stored procedure that returns a result set), the return value
should either be a boolean false, or a result resource.  This has always
been the case since I started using PHP with 4.0.6.  This has allowed me to
use the following idiom to execute a query and get its results:

<quote>
$result = mssql_query('select foo from bar');

while ($row = mssql_fetch_object($result)) {
  //Do something
}
</quote>

This normally works great, even if there are no results.  The
mssql_fetch_object() function is given a proper result resource, but since
there are no rows it returns false and the while loop is never entered.

In the above example I'm using a custom error handler which will trigger if
mssql_query fails.  Let's suppose I didn't do that:

<quote>
if ($result = mssql_query('select foo from bar')) {
  while ($row = mssql_fetch_object($result)) {
    //Do something
  }
} else {
  echo "An error occured with the query";
}
</quote>

The above example breaks when it runs across the problem I mentioned in my
original post.  The mssql_fetch_object() expects a result resource and barfs
when given a boolean.

> There are countless ways in PHP to differentiate the three from each
> other, the easiest are probably:
>
> 1. $result === false
> 2. $result === true
> 3. is_resource($result)

That may be true, but I have hundreds of existing PHP pages that depend on
the old behavior.  Using grep and wc I can see that I'd have to modify 280
calls to mssql_fetch_object() in 112 different files.  To be honest, I use a
database abstraction object, and if I absolutely had to I could work around
this inside my fetch_object() wrapper function, but that's awfully kludgy.

> I have used both the sybase_ct and the mssql extensions with no real
> problems, they are definitely not known to be any less reliable than
> --with-sybase.
>
> --with-mssql is the current recommendation as it ensures source
> compatibility with PHP on Windows, which of course might not be a
> concern to you.

Great, that is good to know.  Thanks a lot for this information.  I'll
probably switch to --with-mssql since that seems to fix this issue anyway.

> Note that the current version of PHP is 4.3.5 and there were changes
> in the Sybase extension, though probably unrelated.

Thanks for the heads up...last time I checked 4.3.4 was the newest one.  I
couldn't upgrade to it because of an unrelated bug, but perhaps it's been
fixed in 4.3.5.

Thanks again...

___________________________________________
Michael Sims
Project Analyst - Information Technology
Crye-Leike Realtors
Office: (901)758-5648  Pager: (901)769-3722
___________________________________________