Skip to Content.
Sympa Menu

freetds - Re: [freetds] old patch

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <james.k.lowden AT alliancebernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] old patch
  • Date: Mon, 10 Jul 2006 17:52:40 -0400

> From: Frediano, VF-IT
> Sent: Monday, July 10, 2006 11:19 AM
>
> trying to fix rpc2.php test (and some done_handling) I came to
> this
> old patch. This is pre 0.63 !!!

You've been working....

>
https://sourceforge.net/tracker/index.php?func=detail&aid=1095806&group_
> id=33106&atid=407808 Do you remember the print problem??

I think so. IIRC, SQL PRINT statement output was getting ignored
instead of being routed to the message handler.

>
> @@ -1304,6 +1308,10 @@
> dbproc->dbresults_state = _DB_RES_INIT;
> return NO_MORE_RESULTS;
> break;
> + case _DB_RES_NEXT_RESULT:
> + case _DB_RES_INIT:
> + tds_free_all_results(tds);
> + break;
> default:
> break;
> }

Well, I suspect at the time libtds was less careful to free its results.
Over time we've moved more responsibility into libtds.

On the same topic, src/dblib/unittests/rpc.c is now coded correctly
(gets parameters & return status after dbresults() returns
NO_MORE_RESULTS) and works! As you can see, several days of code
inspection yielded a two-line change....

I still plan to remove dbresults_state, but it's hard. I think I'll
have to hack on token.c first, and build better functions to read packet
sequences. In case you're curious, here's a cross-reference:

0 dblib.h <global> 130 int dbresults_state;
1 dblib.c _dbresults 1309 dbproc->dbresults_state,
prdbresults_state(dbproc->dbresults_state));
2 dblib.c _dbresults 1310 switch ( dbproc->dbresults_state ) {
3 dblib.c _dbresults 1313 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
4 dblib.c _dbresults 1342 dbproc->dbresults_state =
_DB_RES_RESULTSET_EMPTY;
5 dblib.c _dbresults 1351 dbproc->dbresults_state =
_DB_RES_RESULTSET_ROWS;
6 dblib.c _dbresults 1358 dbproc->dbresults_state,
prdbresults_state(dbproc->dbresults_state));
7 dblib.c _dbresults 1366 switch (dbproc->dbresults_state) {
8 dblib.c _dbresults 1370 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
9 dblib.c _dbresults 1377 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
a dblib.c _dbresults 1391 switch (dbproc->dbresults_state) {
b dblib.c _dbresults 1394 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
c dblib.c _dbresults 1398 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
d dblib.c _dbresults 1415 switch (dbproc->dbresults_state) {
e dblib.c _dbresults 1417 dbproc->dbresults_state =
_DB_RES_NO_MORE_RESULTS;
f dblib.c _dbresults 1421 dbproc->dbresults_state =
_DB_RES_NO_MORE_RESULTS;
g dblib.c _dbresults 1429 dbproc->dbresults_state = _DB_RES_INIT;
h dblib.c dbnextrow 1587 dbproc->dbresults_state,
prdbresults_state(dbproc->dbresults_state));
i dblib.c dbnextrow 1589 if (!resinfo || dbproc->dbresults_state !=
_DB_RES_RESULTSET_ROWS) {
j dblib.c dbnextrow 1632 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
k dblib.c dbsqlok 4267 dbproc->dbresults_state =
_DB_RES_RESULTSET_EMPTY;
l dblib.c dbsqlok 4279 dbproc->dbresults_state =
_DB_RES_NEXT_RESULT;
m dblib.c dbsqlok 4281 dbproc->dbresults_state =
_DB_RES_NO_MORE_RESULTS;
n dblib.c dbsqlok 4288 dbproc->dbresults_state = _DB_RES_SUCCEED;
o dblib.c dbwritetext 5888 dbproc->dbresults_state = _DB_RES_INIT;
p dblib.c dbsqlsend 6358 dbproc->dbresults_state = _DB_RES_INIT;
q dblib.c dbsqlsend 6378 dbproc->dbresults_state = _DB_RES_INIT;
r rpc.c dbrpcsend 272 dbproc->dbresults_state = _DB_RES_INIT;

All this "if state A then action B" is unnecessary, as far as I can
tell. Whether to free memory or not can always be determined by
inspecting the pointer for NULL. Which token to stop on depends on what
the function's purpose. But I don't think we understood that when
dbresults_state got to be so important.

> Oh... have you see (which is the correct english form here...)

[have you seen] ;-)

> src/odbc/unittests/describecol.c test? It use an external file as
> some sort of basic script language for test. Mainly is composed by
> actions (like select, odbc and set commands) and tests (attr). I
> would like to have a script that could tranform dumps to some sort
> of test script one day...

I like this idea. Do you mean you'd like to extract SQL from a TDSDUMP
file?

Regards,

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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