[freetds] mssql_query() returns boolean when stored procedurereturns empty result set
Lowden, James K
LowdenJK at bernstein.com
Fri Apr 2 13:17:29 EST 2004
> 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.
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.
More information about the FreeTDS