FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

John

tds.h:#define TDS_ROW_RESULT        4040
tds.h:#define TDS_ROWFMT_RESULT     4049

Bill
> -----Original Message-----
> From: Wilson, John [SMTP:John.Wilson AT Savvis.net]
> Sent: Thursday, October 24, 2002 9: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: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')