FreeTDS Development Group

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

This problem is also documented the Sybperl Bug list..

I have been trying to figure out why ct_sql() is getting caught in an
infinite loop.  In running some perl code that used to work under OCS12.0,
it now goes into an infinite loop under FreeTDS.

I'm not 100% sure this is a sybperl issue or FreeTDS issue, but the sybperl
test code ct_sql.pl modified to access my DB, is also failing in a similar
way as my (inherited) source code.

Here is the modified ct_sql.pl code which is just calling "select
@@version".
________________________________________________________
#!/usr/local/bin/perl
#
#       @(#)ct_sql.pl   1.2     8/7/95

# Using the special one step query routine ct_sql().

use Sybase::CTlib;

print "creating new CTlib object...\n";
$d = new Sybase::CTlib my_user, my_pass, RTDBASESQL;

# ct_sql() returns a 'reference' to an array:
$ref = $d->ct_sql("select \@\@version");

foreach $line (@$ref)  # 'de-reference' the pointer
{
    print "@$line\n";
}

... 

it does not get past this point...
_____________________________________________________

Here it the TDSDUMP, note comments below:
_____________________________________________________
2002-10-27 17:13:07.947192 inside ct_command()
2002-10-27 17:13:07.947429 inside ct_send()
Sending packet @ 2002-10-27 17:13:07.947688
0000  01 01 00 28 00 00 01 00  73 00 65 00 6c 00 65 00   |...(....s .e.l.e.|
0010  63 00 74 00 20 00 40 00  40 00 76 00 65 00 72 00   |c.t. .@.@ .v.e.r.|
0020  73 00 69 00 6f 00 6e 00                            |s.i.o.n.|


2002-10-27 17:13:07.948044 ct_send() succeeded
2002-10-27 17:13:07.948547 inside ct_results()
Received header @ 2002-10-27 17:13:07.948925
0000  04 01 01 97 00 37 01 00                            |.....7..|


Received packet @ 2002-10-27 17:13:07.949189
0000  81 01 00 00 00 01 00 e7  58 02 00 d1 78 01 4d 00   |........X ...x.M.|
0010  69 00 63 00 72 00 6f 00  73 00 6f 00 66 00 74 00   |i.c.r.o.s .o.f.t.|
0020  20 00 53 00 51 00 4c 00  20 00 53 00 65 00 72 00   | .S.Q.L.  .S.e.r.|
0030  76 00 65 00 72 00 20 00  20 00 32 00 30 00 30 00   |v.e.r. .  .2.0.0.|
0040  30 00 20 00 2d 00 20 00  38 00 2e 00 30 00 30 00   |0. .-. .8 ...0.0.|
0050  2e 00 31 00 39 00 34 00  20 00 28 00 49 00 6e 00   |..1.9.4.  .(.I.n.|
0060  74 00 65 00 6c 00 20 00  58 00 38 00 36 00 29 00   |t.e.l. .X .8.6.).|
0070  20 00 0a 00 09 00 41 00  75 00 67 00 20 00 20 00   | .....A.u .g. . .|
0080  36 00 20 00 32 00 30 00  30 00 30 00 20 00 30 00   |6. .2.0.0 .0. .0.|
0090  30 00 3a 00 35 00 37 00  3a 00 34 00 38 00 20 00   |0.:.5.7.: .4.8. .|
00a0  0a 00 09 00 43 00 6f 00  70 00 79 00 72 00 69 00   |....C.o.p .y.r.i.|
00b0  67 00 68 00 74 00 20 00  28 00 63 00 29 00 20 00   |g.h.t. .( .c.). .|
00c0  31 00 39 00 38 00 38 00  2d 00 32 00 30 00 30 00   |1.9.8.8.- .2.0.0.|
00d0  30 00 20 00 4d 00 69 00  63 00 72 00 6f 00 73 00   |0. .M.i.c .r.o.s.|
00e0  6f 00 66 00 74 00 20 00  43 00 6f 00 72 00 70 00   |o.f.t. .C .o.r.p.|
00f0  6f 00 72 00 61 00 74 00  69 00 6f 00 6e 00 0a 00   |o.r.a.t.i .o.n...|
0100  09 00 45 00 6e 00 74 00  65 00 72 00 70 00 72 00   |..E.n.t.e .r.p.r.|
0110  69 00 73 00 65 00 20 00  45 00 64 00 69 00 74 00   |i.s.e. .E .d.i.t.|
0120  69 00 6f 00 6e 00 20 00  6f 00 6e 00 20 00 57 00   |i.o.n. .o .n. .W.|
0130  69 00 6e 00 64 00 6f 00  77 00 73 00 20 00 4e 00   |i.n.d.o.w .s. .N.|
0140  54 00 20 00 35 00 2e 00  30 00 20 00 28 00 42 00   |T. .5...0 . .(.B.|
0150  75 00 69 00 6c 00 64 00  20 00 32 00 31 00 39 00   |u.i.l.d.  .2.1.9.|
0160  35 00 3a 00 20 00 53 00  65 00 72 00 76 00 69 00   |5.:. .S.e .r.v.i.|
0170  63 00 65 00 20 00 50 00  61 00 63 00 6b 00 20 00   |c.e. .P.a .c.k. .|
0180  32 00 29 00 0a 00 fd 10  00 c1 00 01 00 00 00      |2.)...... ......|


2002-10-27 17:13:07.950061 processing result tokens.  marker is  81
2002-10-27 17:13:07.950296 inside ct_results() process_result_tokens
returned 1 (type 4049)
2002-10-27 17:13:07.950516 processing result tokens.  marker is  d1
2002-10-27 17:13:07.950837 inside ct_results() process_result_tokens
returned 1 (type 4040)
2002-10-27 17:13:07.951441 inside ct_results()
2002-10-27 17:13:07.951671 processing result tokens.  marker is  d1
2002-10-27 17:13:07.951885 inside ct_results() process_result_tokens
returned 1 (type 4040)
2002-10-27 17:13:07.952142 inside ct_results()
[... etc ...]

_____________________________________________________

Note this is the same problem I had with my code.  ct_sql goes into a loop.
I have FreeTDS setup as Version 7.0 accessing MS SQL Server 2000.  This
function has never worked to my knowledge in the current configuration.
Also, note that the ct_results() returns what is expected.
I hope this helps determine what the problem is, I could really use this
code. I'll also look into using nsql() as it appears to be handling the
returns codes differently.
thanks

jd wilson