Skip to Content.
Sympa Menu

freetds - RE: [freetds] mssql_query() returns boolean when stored procedurereturns empty result set

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] mssql_query() returns boolean when stored procedurereturns empty result set
  • Date: Fri, 2 Apr 2004 13:17:29 -0500

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: April 1, 2004 2:05 PM
>
> Jmaes... we get a lot of script (Perl & PHP) problems with examples...
> it's hard to convert these examples in C tests however I
> don't imagine a
> simple script for doing all tests we need... I remember your
> propose of
> a script. Are you thinking something specific ?? Another idea would be
> compile some PHP/Perl tests if available... not that easy however...

The specific thing I had in mind was one general-purpose query processor
(along the lines of tsql) for each client library. I think it should be able
to read its SQL from stdin, write output to stdout, and errors to stderr. It
should be able to handle regular and computed results, but it wouldn't deal
with rpc or dynamic queries (unless we invent a syntax for that, which seems
like more effort than it's worth).

These "batch sql" processors, correctly written, would serve other purposes
beyond simplifying and expanding our testing regimen. They would be useful
in their own right for batch environments (and therefore should probably
reside in src/apps instead of src/*/unittests). And they could serve as a
reference model for anyone writing an application. People frequently want
sample code, and we don't have any really good samples. The standard answer
to "How do I do X in ct-lib?" would become "Look at bsql-ct".

We could use such "batch sql" processors in the unit testing by wrapping them
in a script that understands the PWD file and invokes them appropriately. I
know it's possible to tell autoconf to invoke test scripts; it's just a
matter of figuring out how. (Maybe these wouldn't go in the unittest
directories at all; maybe they justify a src/test or src/app/test directory.

For Perl and PHP, we need the same thing, more or less. If we had a
"bsql-dbi-sybase" Perl script that could read SQL from stdin, etc., we could
feed it the same SQL script we feed any of the other batch processors and see
how it reacts. I assume we could do the same for PHP.

I think the time has come to tackle this, because, as you observed a little
while ago, the problems are getting more subtle. A few years ago there were
examples of integers losing digits in conversion or failures to interpret
tokens in the data stream, the kinds of things that are pretty easy to spot
and test for. Now that the basics are under control, we need more
comprehensive testing. Also, if we make testing relatively easy, then folks
who have PHP, say, installed might be more willing to do a quick
rebuild/relink/test once in a while, just to make sure things still work.

And I think we have the talent among the 700-some subscribers here to write
these processors. Several people here are quite savvy with their chosen
language or API. It's just a small matter of programming.

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





  • RE: [freetds] mssql_query() returns boolean when stored procedurereturns empty result set, Lowden, James K, 04/02/2004

Archive powered by MHonArc 2.6.24.

Top of Page