FreeTDS Development Group

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

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) [mailto:ThompBil AT exchange.uk.ml.com]
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 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')


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