FreeTDS Development Group

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

Daniel Fazekas wrote:
> On Apr 1, 2004, at 4:22, Michael Sims wrote:
>> 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.
>
> The inconvenience of rewriting all the old code having the weaker
> error checking is a very valid concern. It's my turn however to
> respectfully disagree on the point that strict error checking is in
> any way kludgy.

We're really only disagreeing on semantics.  Personally I don't consider
having to resort to is_resource() to be strict error checking, I consider
that working around a "bug".  If it's not a bug, it's at least unexpected
behavior that violates the principle of least surprise.  Given that the
following statements are true:

1. When given an SQL query that returns an empty result set, pg_query()
returns a result resource, or boolean false on failure.
2. When given an SQL query that returns an empty result set, mysql_query()
returns a result resource, or boolean false on failure.
3. When given an SQL query that returns an empty result set, mssql_query()
returns a result resource, or boolean false on failure, UNLESS the query as
a stored procedure, in which case boolean TRUE is returned.

I would certainly say #3 is at least "incorrect" behavior, if not a bug,
especially since it changed when switching FreeTDS versions, and doesn't
occur when using --with-mssql or --with-sybase-ct.  Using is_resource(),
while most likely being the proper paranoid thing to do, seems to me to be
slightly kludgy when it is only required in this one exceptional case.  That
is just my humble opinion, and I can respect that others may view the
situation differently.

> And on the point of "breaking," even in the original case, the
> _fetch_* call would simply emit a warning message to where you set
> error logging to write to, and still return false and the code would
> work the same way it did when confronted with an empty result
> resource in the original case.

That wouldn't be true in my environment, since I use a custom error handler
that halts the script execution on any PHP error that is higher than notice
level.  In the cases where I reasonably expect that a warning might be
triggered, I'll prefix the function call with "@", but this isn't one of
those cases.

> Since you already have the fetch call inside a wrapper, it should be
> easy enough to add a check there, which could as well have been there
> already anyway, regardless of whether you ever encountered this bug or
> not.
[snip]

That is true.

> I hope you aren't offended by me offering this workaround or
> suggesting that you should use an is_resource() check in any future
> code.

Certainly not.  I would also like to note that my original use of terms like
"broken" and "kludgy" were in no way meant to be disrespectful to any of the
developers/contributors to FreeTDS or PHP.  If it was interpreted this way,
I apologize.

Thanks again for your help...

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