FreeTDS Development Group

["Wilson, John" <John.Wilson AT Savvis.net>]

Nick,
I'm downloaded Wednesday's daily build due to the previous problem I had
with the NULL fields in the BCP process.  That problem has been resolved...
thanks for putting the patch in.
I also picked up one source file in ctlib, but don't recall which one it was
right now... hopefully, this is not the problem.  I also have one of the
blk_ methods stubbed out since (allegedly :-) ) FreeTDS does not support the
blk_ methods yet.

I think I've found an issue in the API for ct_results().

The docs I have show the method call as:
    $dbh->ct_results($res_type [,$textBind])

The CTlib.xs file shows:
    int ct_results(dbp, restype, textBind = 1)

The old code is passing in only $res_type.  
I'm digging into how to fix this now.
Thanks for the help... 
If there are any other suggestions, please let me know.
regards,
john

-----Original Message-----
From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
Sent: Thursday, October 24, 2002 3:39 PM
To: TDS Development Group
Subject: [freetds] RE: infinte loop


Are you using a release or current CVS?  I can't find this information
anywhere in this thread...

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Thursday, October 24, 2002 4:31 PM
To: TDS Development Group
Subject: [freetds] RE: infinte loop


Additional info from the tdsdump file.  This shows in the ASCII column that
the select statement is being sent and it's "inside ct_send()". [...]
2002-10-24 14:54:35.887781 inside ct_command() 2002-10-24 14:54:35.887977
inside ct_send() Sending packet @ 2002-10-24 14:54:35.888180
0000  01 01 00 98 00 00 01 00  73 00 65 00 6c 00 65 00   |........s .e.l.e.|
0010  63 00 74 00 20 00 64 00  61 00 74 00 75 00 6d 00   |c.t. .d.a .t.u.m.|
0020  5f 00 64 00 65 00 66 00  5f 00 69 00 64 00 2c 00   |_.d.e.f._ .i.d.,.|
0030  20 00 69 00 70 00 61 00  64 00 64 00 72 00 2c 00   | .i.p.a.d .d.r.,.|
0040  20 00 76 00 61 00 72 00  69 00 61 00 62 00 6c 00   | .v.a.r.i .a.b.l.|
0050  65 00 2c 00 20 00 69 00  6e 00 73 00 74 00 61 00   |e.,. .i.n .s.t.a.|
0060  6e 00 63 00 65 00 20 00  66 00 72 00 6f 00 6d 00   |n.c.e. .f .r.o.m.|
0070  20 00 44 00 41 00 54 00  55 00 4d 00 2e 00 64 00   | .D.A.T.U .M...d.|
0080  62 00 6f 00 2e 00 64 00  61 00 74 00 75 00 6d 00   |b.o...d.a .t.u.m.|
0090  5f 00 64 00 65 00 66 00                            |_.d.e.f.|

2002-10-24 14:54:35.888676 ct_send() succeeded
2002-10-24 14:54:35.889062 inside ct_results()
Received header @ 2002-10-24 14:54:35.890422
0000  04 00 10 00 00 3f 01 00                            |.....?..|

jdw> comment> this appears to return column data and dies
about 8 bytes before it's completed.  Possilbly a counter problem?

Received packet @ 2002-10-24 14:54:35.890718
0000  81 04 00 00 00 08 00 6c  11 0a 00 0c 64 00 61 00   |.......l. ...d.a.|
0010  74 00 75 00 6d 00 5f 00  64 00 65 00 66 00 5f 00   |t.u.m._.d .e.f._.|
0020  69 00 64 00 00 00 08 00  a7 20 00 06 69 00 70 00   |i.d......  ..i.p.|
0030  61 00 64 00 64 00 72 00  00 00 08 00 a7 80 00 08   |a.d.d.r.. .......|
0040  76 00 61 00 72 00 69 00  61 00 62 00 6c 00 65 00   |v.a.r.i.a .b.l.e.|
0050  00 00 08 00 a7 50 00 08  69 00 6e 00 73 00 74 00   |.....P..i .n.s.t.|
0060  61 00 6e 00 63 00 65 00  d1 05 01 e6 96 98 00 0c   |a.n.c.e.. .......|
0070  00 31 36 37 2e 37 36 2e  33 2e 32 32 31 18 00 2e   |.167.76.3 .221...|
0080  31 2e 33 2e 36 2e 31 2e  32 2e 31 2e 32 35 2e 32   |1.3.6.1.2 .1.25.2|
0090  2e 33 2e 31 2e 35 2e 01  00 35 d1 05 01 e7 96 98   |.3.1.5... 5......|
[...]
0fc0  e2 e4 00 0e 00 31 36 37  2e 37 36 2e 31 32 37 2e   |.....167. 76.127.|
0fd0  31 30 31 11 00 2e 31 2e  33 2e 36 2e 31 2e 32 2e   |101...1.3 .6.1.2.|
0fe0  31 2e 31 2e 31 2e 01 00  30 d1 05 01 01 e2 e4 00   |1.1.1...0 .......|
0ff0  0e 00 31 36 37 2e 37 36                            |..167.76|

2002-10-24 14:54:35.897704 processing result tokens.  marker is  81
2002-10-24 14:54:35.897899 inside ct_results() process_result_tokens
returned 1 (type 4049)
2002-10-24 14:54:35.898077 processing result tokens.  marker is  d1
2002-10-24 14:54:35.898254 inside ct_results() process_result_tokens
returned 1 (type 4040)
2002-10-24 14:54:35.899049 inside ct_results()
etc...

I'm looking for the meaning of 4040 and 4049 now.
regards,
john

-----Original Message-----
From: Wilson, John 
Sent: Thursday, October 24, 2002 3:11 PM
To: TDS Development Group
Subject: [freetds] RE: infinte loop


Bill,
I think there are some changes in the way the low level ct_ methods 
work between OCS 12.0 and FreeTDS.  

I've not been able to get sqsh to run.  I've got the binary
for sqsh 2.1 and I'm getting this error:

        $ sqsh -S RTDBASESQL -U user -P passnotshown
        sqsh-2.1 Copyright (C) 1995-2001 Scott C. Gray
        [...]
        \connect: Unable to install message callback

I would like to try this but I need to fix the real problem 
right now.

I've tracked down the problem to this section of code:

______________________________________________________
    if ( $db->ct_execute($cmd) != &CS_SUCCEED ) {
        internalSybaseStackTrace();
        return ( -1, undef );
    }

    if ($sybase::debug_sql) { print STDERR "==>>>sql = $cmd\n" }

    $max      = $db->{'MaxRows'};
    $res_type = 0;                  # avoid 'unitialized variable'
warnings...
    $flag     = 0 unless $flag;

    #jdw>
    if ($sybase::debug_results) { print "Sybase_ct_sql: entering while
loop...\n"; }

--->while ( ( $rc = $db->ct_results($res_type) ) == &CS_SUCCEED ) {
<--------
        if ($sybase::debug_results) {
            printf STDERR "Sybase_ct_sql: results rc=$rc
res_type=$res_type\n";
        }
        if ( $res_type == &CS_CMD_FAIL ) {
            if ( $SYBASE_CT_SQL::save_error == 1205 ) {
                print "Sybase_ct_sql: save_error = 1205, calling
ct_res_info()...\n";
                # Only retry if not in a transaction
                my $tran_level = $db->ct_res_info(&CS_TRANS_STATE);
                [...]
______________________________________________________

The script output:

blog1: 10/24/2002 14:37:06 executing sql command:^M
select datum_def_id, ipaddr, variable, instance from DATUM.dbo.datum_def^M
calling SybaseSimpleSQL...
SybaseSimpleSQL: begin timing...^M
SybaseSimpleSQL: login.dbh= Sybase::CTlib=HASH(0x29a3c4)^M
SybaseSimpleSQL: Entering^M
SybaseSimpleSQL: rowcallback defined...^M
Sybase_ct_sql:^M
        db=Sybase::CTlib=HASH(0x29a3c4)^M
        cmd=select datum_def_id, ipaddr, variable, instance from
DATUM.dbo.datum_def^M
        sub=CODE(0x22bbc4)^M
        flag=1^M
==>>>sql = select datum_def_id, ipaddr, variable, instance from
DATUM.dbo.datum_def^M
Sybase_ct_sql: entering while loop...^M
Sybase_ct_sql: results rc=1 res_type=4040^M
Sybase_ct_sql: results rc=1 res_type=4040^M
Sybase_ct_sql: results rc=1 res_type=4040^M
Sybase_ct_sql: results rc=1 res_type=4040^M
etc...

I'm investigating if the $res_type set to 0 makes any difference in the
behavior of ct_results().  Also I'm looking for the best source of info on
the data types, the info returned in tdsdump and the above res_type 4040.
What does this mean?  Maybe ct_resuls() is not able to handle this?  Or is
it my code?  It would appear to be the former, assuming sending in the
$res_type = 0 is not hurting anything.

Maybe this while-loop needs to check for this other return code?  Which
brings me to ask where do I find these return codes for FreeTDS?

regards,
jd 


-----Original Message-----
From: Thompson, Bill D (London) 
Sent: Thursday, October 24, 2002 10:52 AM
To: TDS Development Group
Subject: [freetds] RE: infinte loop


John,

> What's interesting to note, is that this perl code is currently running
> against Sybase's CTlib libraries (Sybase
Client-Library/12.0/P/SPARC/Solaris
> 2.5.1/1/OPT/Mon Oct  4 12:07:29 1999).  So what would have changed in the
> ct_results() processing between the Sybase version and FreeTDS version?

Well, plenty might be different. 
Given it's complexity, It's entirely possible that I've misunderstood how
the results processing is supposed to work!

> I'm using tsql to test some of the select/insert SQL calls found in the
> source code.  Some errors are not accepting the table name w/o prefixing
it
> with the DB name, e.g., DATUM.dbo.datum_def vs datum_def.  I suspect that
> some of the SQL syntax may be more restrictive with SQL Server 2000.
> Another interesting observation is that after fixing the SQL syntax, under
> tsql, the command works, but not when ran programmatically.  Again, some
> re-working of the source would help.

No offence to the authors of that fine program, but I don't think tsql is
the right tool for the job here.
It was written to provide a very basic test harness that would help new
freetds users to test basic connectivity to their databases, without having
to bring in any other code that might add complexity. and thus make basic
testing more difficult.

Once you're up and running connectivity-wise, I'd recommend you use sqsh
1.7, which has the added advantage of using the ct library API . 

send me the perl code, if it's not too unwieldy or sensitive!

Bill

> -----Original Message-----
> From: Wilson, John 
> Sent: Thursday, October 24, 2002 4:37 PM
> To:   TDS Development Group
> Subject:      [freetds] RE: infinte loop
> 
> Bill,
> Thanks for this information.  The software I'm working on was inherited,
> so
> I have a lot to learn about the ct_ methods and the protocol.  
> 
> I think there is a better way to handle this process using
> DBI/DBD::Sybase.
> The perl source is using Sybase::CTlib methods and I've been trying to get
> them to work using FreeTDS connecting to SQL Server 2000.  I've managed to
> get the FreeTDS Sybase::CTlib working with TDSVER set to version 7.0.
> I've
> found some conflicting documentation that says I should be using version
> 8.0, but 7.0 is working pretty well, with the exception of this infinite
> looping problem... which may very well be in our perl code.
> 
> What's interesting to note, is that this perl code is currently running
> against Sybase's CTlib libraries (Sybase
> Client-Library/12.0/P/SPARC/Solaris
> 2.5.1/1/OPT/Mon Oct  4 12:07:29 1999).  So what would have changed in the
> ct_results() processing between the Sybase version and FreeTDS version?
> 
> I'm using tsql to test some of the select/insert SQL calls found in the
> source code.  Some errors are not accepting the table name w/o prefixing
> it
> with the DB name, e.g., DATUM.dbo.datum_def vs datum_def.  I suspect that
> some of the SQL syntax may be more restrictive with SQL Server 2000.
> Another interesting observation is that after fixing the SQL syntax, under
> tsql, the command works, but not when ran programmatically.  Again, some
> re-working of the source would help.
> 
> I'll dig into this and if I find some interesting things to pass along I
> will.  I think I need to review the processing of the ct_results first and
> make sure this is being done correctly.
> regards,
> jd 
> 
> -----Original Message-----
> From: Thompson, Bill D (London)
> Sent: Thursday, October 24, 2002 3:21 AM
> To: TDS Development Group
> Subject: [freetds] RE: infinte loop
> 
> 
> Hi John,
> 
> I would need to see what code you are running that generates this loop, as
> it appears possible that there is a fault in the ctlib code you are
> executing rather than in freertds itself.
> 
> In short, from your tdsdump, I can see the following happening.
> 
> You've called ct_results(). This has read a "RESULTS" message from the
> server (marker 81).
> If you had called ct_config previously, setting the property
> CS_EXPOSE_FMTS
> to CS_TRUE, this would then have returned control to your program, with
> return code of CS_SUCCEED and result_type of CS_ROWFMT_RESULT.
> 
> If you had not called ct_config previously, ct_results() would have gone
> on
> to read the next message from the server.
> This message is a "ROW" message (marker d1). 
> As I read the ct_results code, this should have then returned control to
> your program, with return code of CS_SUCCEED and result_type of
> CS_ROW_RESULT.
> 
> When you set up a ct_results() loop, after each successful return
> (CS_SUCCEED) you should examine the result_type variable passed in to
> ct_results().
> 
> When the result type is CS_ROW_RESULT, it indicates that there is data
> available which requires fetching, using a call to ct_fetch(). If you
> don't
> fetch this data, but continue to call ct_results(), it will continue to
> tell
> you that you have rows to fetch, ad-infinitum I suppose. 
> 
> That's my take on what's happening here.
> 
> Very recently, a patch has been applied which extensively reworked the
> results/row processing. 
> In the course of doing this, I wnt back to basics on the ctlib code, and
> basically re-coded it from the ctlib manual pages. 
> The above is my understanding of how the ct-lib results processing should
> work. 
> Here's a small excerpt from the ct_results manual page which illustrates
> this.
> 
> --------
> 
> The simplest way to read results is in a loop that terminates when
> ct_results does not return CS_SUCCEED. After the loop, an application can
> use a case-type statement to test ct_results' final return code and
> determine why the loop terminated. The following rules apply to the logic
> of
> a results handling loop: 
>       ct_results returns CS_SUCCEED as long as results are still available
> to the application.
>       When ct_results sets result_type to a value that indicates fetchable
> result data, the application must fetch or cancel the data before
> continuing.
>       ct_results sets the value of result_type to CS_CMD_DONE to indicate
> that the results of a logical command have been completely processed.
> Logical commands are explained under "ct_results and logical commands"
> <@ebt-link;pt=52813?target=%25N%15_53584_START_RESTART_N%25>.
>       ct_results returns CS_END_RESULTS when all results have been
> processed successfully.
>       ct_results returns CS_CANCELED if the application cancels the
> results with ct_cancel(CS_CANCEL_ALL) or ct_cancel(CS_CANCEL_ATTN).
> 
> -------
>   
> Note the part that says "the application must fetch or cancel the data
> before continuing". I'm not clear how one "cancels the data" before
> continuing, though.

I found a ct_cancel() menthod but have not looked into this yet.

> 
> I hope this helps,
> 
> Bill
> 
> 
> > -----Original Message-----
> > From:       Wilson, John [SMTP:John.Wilson AT savvis.net]
> > Sent:       Wednesday, October 23, 2002 10:37 PM
> > To: TDS Development Group
> > Subject:    [freetds] RE: infinte loop
> > 
> > Sorry all, I ment to edit this further to help out.
> > 
> > the tdsdump starts out like this...
> > 
> > 
> > Received packet @ 2002-10-23 16:16:54.157635
> > 0000  81 04 00 00 00 08 00 6c  11 0a 00 0c 64 00 61 00   |.......l.
> > ...d.a.|
> > 0010  74 00 75 00 6d 00 5f 00  64 00 65 00 66 00 5f 00   |t.u.m._.d
> > .e.f._.|
> > 0020  69 00 64 00 00 00 08 00  a7 20 00 06 69 00 70 00   |i.d......
> > ..i.p.|
> > 0030  61 00 64 00 64 00 72 00  00 00 08 00 a7 80 00 08   |a.d.d.r..
> > .......|
> > 0040  76 00 61 00 72 00 69 00  61 00 62 00 6c 00 65 00   |v.a.r.i.a
> > .b.l.e.|
> > 0050  00 00 08 00 a7 50 00 08  69 00 6e 00 73 00 74 00   |.....P..i
> > .n.s.t.|
> > 0060  61 00 6e 00 63 00 65 00  d1 05 01 e6 96 98 00 0c   |a.n.c.e..
> > .......|
> > [...]
> > 0fb0  32 2e 32 2e 31 2e 32 31  2e 01 00 32 d1 05 01 00   |2.2.1.21.
> > ..2....|
> > 0fc0  e2 e4 00 0e 00 31 36 37  2e 37 36 2e 31 32 37 2e   |.....167.
> > 76.127.|
> > 0fd0  31 30 31 11 00 2e 31 2e  33 2e 36 2e 31 2e 32 2e   |101...1.3
> > .6.1.2.|
> > 0fe0  31 2e 31 2e 31 2e 01 00  30 d1 05 01 01 e2 e4 00   |1.1.1...0
> > .......|
> > 0ff0  0e 00 31 36 37 2e 37 36                            |..167.76|
> > 
> > 
> > 2002-10-23 16:16:54.165242 processing result tokens.  marker is  81
> > 2002-10-23 16:16:54.165502 inside ct_results() process_result_tokens
> > returned 1 (type 4049)
> > 2002-10-23 16:16:54.165702 processing result tokens.  marker is  d1
> > 2002-10-23 16:16:54.165909 inside ct_results() process_result_tokens
> > returned 1 (type 4040)
> > 2002-10-23 16:16:54.166884 inside ct_results()
> > 2002-10-23 16:16:54.167070 processing result tokens.  marker is  d1
> > 2002-10-23 16:16:54.167233 inside ct_results() process_result_tokens
> > returned 1 (type 4040)
> > 
> > It appears to be running into some limit here @ x0ff0 and then gets
> caught
> > up in this loop.
> > It appears to be in ctlib/ct.c or related to this.
> > 
> > john
> > 
> > 
> > -----Original Message-----
> > From: Wilson, John 
> > Sent: Wednesday, October 23, 2002 4:28 PM
> > To: TDS Development Group
> > Subject: [freetds] infinte loop
> > 
> > 
> > TDS Group:
> > 
> > In the ongoing effort to get the old Sybase code working, I've run into
> an
> > infinte loop at this point.  It fills up the tdsdump.txt file pretty
> > quickly
> > BTW.
> > 
> > 2002-10-23 16:16:54.165242 processing result tokens.  marker is  81
> > 2002-10-23 16:16:54.165502 inside ct_results() process_result_tokens
> > returned 1 (type 4049)
> > 2002-10-23 16:16:54.165702 processing result tokens.  marker is  d1
> > 2002-10-23 16:16:54.165909 inside ct_results() process_result_tokens
> > returned 1 (type 4040)
> > 2002-10-23 16:16:54.166884 inside ct_results()
> > 2002-10-23 16:16:54.167070 processing result tokens.  marker is  d1
> > 2002-10-23 16:16:54.167233 inside ct_results() process_result_tokens
> > returned 1 (type 4040)
> > 2002-10-23 16:16:54.167448 inside ct_results()
> > 
> > I'm looking into this now, but thought someone else may already be aware
> > of
> > it.
> > 
> > regards,
> > jd


---
You are currently subscribed to freetds as: [john.wilson AT savvis.net]
To unsubscribe, forward this message to
$subst('Email.Unsub')

---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


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.



---
You are currently subscribed to freetds as: [john.wilson AT savvis.net]
To unsubscribe, forward this message to
$subst('Email.Unsub')