FreeTDS Development Group

["Lowden, James K" <james.k.lowden AT alliancebernstein.com>]

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