Skip to Content.
Sympa Menu

freetds - RE: [freetds] FreeTDS 0.62.4 problems with COALESCE in Stored Procedures

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] FreeTDS 0.62.4 problems with COALESCE in Stored Procedures
  • Date: Wed, 17 Nov 2004 11:32:02 -0500

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






Archive powered by MHonArc 2.6.24.

Top of Page