FreeTDS Development Group

[Michael Peppler <mpeppler AT peppler.org>]

On Mon, 2002-10-28 at 08:33, Wilson, John wrote:
> Michael, 
> Thanks for the reply.  The infinite loop is in the ct.c code, but I thought
> it was because of the logic in CTlib.pm.  Some of the logic has changed in
> FreeTDS and I will be picking up the daily build.
> 
> The one question I do have deals with the how nsql() and ct_sql() handle the
> this line:
> 
> # in ct_sql() you have:
>       next unless $fetchable{$res_type};
> 
> # in nsql() you have:
>       next unless $db->ct_fetchable($restype);
> 
> You have a sub called ct_fetchable() also in this code, which I think these
> are functionally equivalent... if you can verify this it would be
> appreciated.

They are indeed the same. There is a hash value in CTlib.pm that is
called %fetchable:
@fetchable{
  &CS_ROW_RESULT,
  &CS_PARAM_RESULT,
  &CS_STATUS_RESULT,
  &CS_CURSOR_RESULT,
  &CS_COMPUTE_RESULT} = (1) x 5;

sub ct_fetchable
{
    $fetchable{$_[1]};
}

So both forms are acceptable, with
        unless $fetchable($restype};
being a tad faster, but a little bit too chummy with the Sybase::CTlib
internals.

Michael



> -----Original Message-----
> From: Michael Peppler [mailto:mpeppler AT peppler.org]
> Sent: Monday, October 28, 2002 10:14 AM
> To: TDS Development Group
> Subject: [freetds] RE: followup on infinite loop issue
> 
> 
> I'm almost 100% certain that this is a FreeTDS problem, as this works
> perfectly well when using the Sybase libraries.
> 
> Anyway, to clarify what ct_sql() does:
> 
> 
>     while(($rc = $db->ct_results($res_type)) == &CS_SUCCEED) {
> # The $rc variable is used *after* the loop to check for other types of
> # failures (i.e. if ct_results returns CS_FAIL, for example)
> 
> # If the $res_type == CS_CMD_DONE, then fetch the rowcount and store it
> # in $db->{ROW_COUNT}
>         $db->{'ROW_COUNT'} = $db->ct_res_info(&CS_ROW_COUNT)
>             if $res_type == &CS_CMD_DONE;
> 
> # If the $res_type == CS_CMD_FAIL then set a "fail" flag (used below)
>       $fail = 1 if ($res_type == &CS_CMD_FAIL);
> 
> # Go to next result if the current result type is not "fetchable" 
> # (CS_ROW_RESULT, CS_STATUS_RESULT, etc)
>       next unless $fetchable{$res_type};
> 
> # If the ct_sql_nostatus variable is set, and if the result type 
> # is a CS_STATUS_RESULT, then fetch the data and throw it away.
> # The point here being that if you execute a stored proc and are
> # looking for the rows SELECTed in the proc, having an additional
> # entry in the array returned from ct_sql() with the procs return status
> # can be annoying
>       if($Sybase::CTlib::ct_sql_nostatus && $res_type ==
> &CS_STATUS_RESULT) {
>           while ($data = $db->ct_fetch(0, 1)) {
>               ;   #skip return codes from procs...
>           }
>       }
> 
> # Now fetch any rows, in either hash or array format.
>         while ($data = $db->ct_fetch($flag, 1)) {
>             if (defined $sub) {
>               if($flag) {
>                   &$sub(%$data);
>               } else {
>                   &$sub(@$data);
>               }
>             } else {
>               if($flag) {
>                   push(@res, {%$data});
>               } else {
>                   push(@res, [@$data]);
>               }
>             }
>         }
>     }
>     if($db->{'MaxRows'}) {
>       $db->ct_options(&CS_SET, &CS_OPT_ROWCOUNT, 0, &CS_INT_TYPE);
>     }
>     $db->{RC} = $fail ? CS_FAIL : $rc;
>     wantarray ? @res : \@res;  # return the result array
> 
> 
> I don't know where this goes into an infinite loop. You could try
> running it with debugging turned on (Sybase::CTlib::debug(0xffffffff))
> and see what calls it tries to execute...
> 
> Michael
> 
> On Mon, 2002-10-28 at 06:20, Wilson, John wrote:
> > Thanks Bill,
> > I also noticed this:
> > at 1) I don't understand why there is an if statement here. 
> >       Was this ment to be an assignment?
> > at 2) was there some intent on using $data within the while loop here?
> > 
> > Hopefully Michael can shed some light on this one.
> > In the mean time, I'll try and use nsql().
> > thanks
> > jd wilson
> > _______________________________________________________________
> >     while(($rc = $db->ct_results($res_type)) == &CS_SUCCEED) {
> >         $db->{'ROW_COUNT'} = $db->ct_res_info(&CS_ROW_COUNT)
> > 
> > 1)            if $res_type == &CS_CMD_DONE;
> > 
> >     $fail = 1 if ($res_type == &CS_CMD_FAIL);
> >     next unless $fetchable{$res_type};
> > 
> >     if($Sybase::CTlib::ct_sql_nostatus && $res_type ==
> > &CS_STATUS_RESULT) {
> > 2)      while ($data = $db->ct_fetch(0, 1)) {
> >             ;   #skip return codes from procs...
> >         }
> >     }
> >     ....
> >     }
> > _________________________________________________________________
> > 
> > -----Original Message-----
> > From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> > Sent: Monday, October 28, 2002 3:40 AM
> > To: TDS Development Group
> > Subject: [freetds] RE: followup on infinite loop issue
> > 
> > 
> > I'm no expert by ANY MEANS, but it appears that nsql() and ct_sql are
> subtly
> > different in one respect, although whether this is significant I don't
> know:
> > 
> > ct_sql :
> > 
> > while(($rc = $db->ct_results($res_type)) == &CS_SUCCEED) {
> >     ...
> >     next unless $fetchable{$res_type};
> >     ...
> > }
> > 
> > nsql:
> > 
> > while($db->ct_results($restype) == &CS_SUCCEED) {
> >     ...
> >     next unless $db->ct_fetchable($restype);
> >     ...
> > }
> > 
> > 
> > Certainly, an inability to spot that there is some data that needs
> fetching
> > before looping round and calling ct_results again would explain the
> symptoms
> > you are seeing...
> > 
> > 
> > Bill
> > > -----Original Message-----
> > > From:     Wilson, John [SMTP:John.Wilson AT savvis.net]
> > > Sent:     Monday, October 28, 2002 12:36 AM
> > > To:       TDS Development Group
> > > Subject:  [freetds] followup on infinite loop issue
> > > 
> > > 
> > > 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
> > > 
> > > 
> > > ---
> > > 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')
> > 
> > ---
> > You are currently subscribed to freetds as: [mpeppler AT peppler.org]
> > To unsubscribe, forward this message to
> $subst('Email.Unsub')
> > 
> -- 
> Michael Peppler / mpeppler AT peppler.org / http://www.mbay.net/~mpeppler
> mpeppler AT zetatools.com / ZetaTools, Inc / http://www.zetatools.com
> ZetaTools: Call perl functions as Sybase stored procedures!
> 
> ---
> You are currently subscribed to freetds as: [mpeppler AT peppler.org]
> To unsubscribe, forward this message to 
> leave-freetds-91463H AT franklin.oit.unc.edu
> 
-- 
Michael Peppler / mpeppler AT peppler.org / http://www.mbay.net/~mpeppler
mpeppler AT zetatools.com / ZetaTools, Inc / http://www.zetatools.com
ZetaTools: Call perl functions as Sybase stored procedures!

Attachment: signature.asc
Description: This is a digitally signed message part