FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: David Clark
> Sent: Tuesday, November 16, 2004 2:59 PM
> 
> This
> problem only occurs on the newest of our web servers, which is running
PHP
> 4.3.9 (on Apache 2) with FreeTDS 0.62.4 installed.
> 
> Upon investigation, it turned out that there was a statement in the
stored
> procedure that was calling the COALESCE() function on two database
fields,
> both of which could be NULL at the same time (and for a small fraction
of
> the records this was exactly the case).  When I called just this
SELECT
> query through PHP I received no results - when I modified the
COALESCE()
> call to include a third parameter that was guaranteed to be non-NULL,
the
> results appeared correctly.
...
> how can the statements WITHIN the stored procedure be affected
> by the client making the call?  Isn't the stored procedure processed
on the
> database server itself?

A TDSDUMP log of the session would be very helpful.  If it's large, post
a link to it.  Please indicate which results are incorrect.  

There is more than one way to execute a stored procedure.  If you embed
the call in ordinary SQL text, as in "execute sp_who 'active'", the
whole thing takes place on the server, yes.  (That's of course the case
from isql and such, too.)  

But if you're using an API designed explicitly for running stored
procedures -- perhaps because you find it easier to pass parameters that
way -- then quite a lot goes on under the hood.  Your procedure in that
case (on Microsoft servers) is actually executed by another procedure
that is called by FreeTDS.  That feat is the product of a lot of reverse
engineering, and it's possible you found a bug.  Let's just hope the log
makes clear what went awry.  

There is another possibility.  The treatment of NULL varies according to
connection properties, and ODBC and db-lib use different defaults for
them.  Try your query from isql.exe, which uses db-lib.  You might also
try FreeTDS's tsql and bsqldb.  If you get results consistent with
Microsoft's Query Analyzer, you know connection properties are not the
issue.  

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.