FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Ok, I was able to replicate the problem.  It seems to be related to the 
ct_cancel() function not being implemented. DBD::Sybase calls ct_cancel 
inside $sth->finish.  I'll see what I can do about it.

In the meantime, a workaround would be to do something like 

while ($sth -> fetchrow) {} 

to allow it to cleanup the result set. I'll try to get a real fix for it 
though.
DBD::Sybase on the real ctlib does not error but then it does not set the 
$sth->rows either unless you completely process the results. So, your code 
would not return a valid result for $sth->rows if you needed it (in either 
freetds or the real ctlib).

So, the best thing is to call $sth->fetchrow until it returns 0.  But 
freetds does exhibit some wrong behaviour and I'll fix that.

Brian

On 09/17/99, ""Kevin Wormington" <kworm AT sofnet.com>" wrote:
> Below is the sub-routine that runs the select, the prepareandexecute
> function just performs some error checking wrapped around a normal prepare
> and execute along with retry/re-connect code.  The code would normally not
> find any matching rows on the RadAttributes select, it does find the user
> from the customer table.  This may not be a result of the code below, but
> that I have noticed that DBD::Sybase gets an error if rows are not found on
> a select as follows:
> 
> Can't get DBI::st=HASH(0x8114470)->{NAME}: unrecognised attribute at login.t
> line 59.
> 
> --- code snippet for above error ----
> 
> ($sth = $dbh->prepare("select * from sometable where somefield =
> 'somenonexistantvalue'"))
>     and print "ok 3\n"
>     or print "not ok 3\n";
> if($sth->execute) {
>     print "ok 4\n";
>     print "Fields: $sth->{NUM_OF_FIELDS}\n";
>     print "Names: @{$sth->{NAME}}\n";
>     print "Null:  @{$sth->{NULLABLE}}\n";
>     my $rows = 0;
>     while(@dat = $sth->fetchrow) {
>         ++$rows;
>         foreach (@dat) {
>             $_ = '' unless defined $_;
>         }
>         print "@dat\n";
>     }
>     ($rows == $sth->rows)
>         and print "ok 5\n"
>             or print "not ok 5\n";
>     $sth->finish;
> }
> 
> 
> 
> --------------------------------------------
> perl sub-routine snippet from Radiator DBD::Sybase 0.20
> --------------------------------------------
> 
> sub findUser
> {
>     my ($self, $name, $p) = @_;
> 
>     # (Re)-connect to the database if necessary,
>     return undef
>         if !$self->reconnect;
> 
>     # We have to change User-Name in the request so we can
>     # use %n etc in AuthSelect
> 
>     my $q = "select id, username, password, active, timeleft, blockuser
>              from customer where username='$name'";
> 
>     my $sth = $self->prepareAndExecute($q);
>     return undef unless $sth;
> 
>     my $user;
>     my ($cust_id, $username, $password, $active, $timeleft, $blockuser);
>     if (($cust_id, $username, $password, $active, $timeleft, $blockuser) =
> $sth-
> >fetchrow)
>     {
> #       print "$cust_id, $password, $username, $timeleft, $blockuser\n";
>         $sth->finish;
> 
> 
>         my ($attr_id, $attr_name, $attr_data, $attr_value, $attr_type);
>         $q = "select ra.RadAttributeID, Data, Value, Type
> from RadConfigs rc, RadAttributes ra
> where ra.RadAttributeID = rc.RadAttributeID and rc.AccountID=$cust_id";
>         $sth = $self->prepareAndExecute($q);
>         return undef unless $sth;
>         my $got_configs; # Dont get Account Type Configs if there are
> per-user
>         while (($attr_id, $attr_data, $attr_value, $attr_type)
>                = $sth->fetchrow)
>         {
> #           print "  Per User Options - $attr_id, $attr_data, $attr_value,
> $attr
> _type\n";
>             $got_configs++;
>             # Dictionaries may not agree, so we use the
>             # attribute number to find the name
>             my @attrDetails = $main::dictionary->attrByNum($attr_id);
>             if ($attr_type == 1) # integer
>             {
>                 $user->get_reply->add_attr($attrDetails[0],
>                                            $attr_value);
>             }
>             else
>             {
>                 $user->get_reply->add_attr($attrDetails[0],
>                                            $attr_data);
>             }
>         }
>         $sth->finish;
> 
> -----Original Message-----
> From: Brian Bruns <camber AT ais.org>
> To: TDS Development Group <freetds AT franklin.oit.unc.edu>
> Date: Friday, September 17, 1999 12:06 PM
> Subject: [freetds] Re: FreeTDS and DBD::Sybase
> 
> 
> >Hi,
> >
> >This will happen if you have not completely processed the select that was
> >issued prior to this one.  Could you post that snippet of code (the
> >processing of the previous select) and some details about what it should be
> >returning.
> >
> >
> >Brian
> >
> >On 09/17/99, ""Kevin Wormington" <kworm AT sofnet.com>" wrote:
> >> Hi all,
> >>
> >> I have just recently grabbed a CVS snapshot of 0.47 freetds and got it
> >> compiled and working with DBD::Sybase 0.20.  I am attempting to use this
> >> with Radiator (a radius server in perl).  It works for the most part, but
> I
> >> get an error from a select as follows:
> >>
> >> Fri Sep 17 09:45:30 1999: ERR: Execute failed for 'select
> ra.RadAttributeID,
> >> Dat
> >> a, Value, Type
> >> from RadConfigs rc, RadAttributes ra
> >> where ra.RadAttributeID = rc.RadAttributeID and rc.AccountID=3509':
> Server
> >> messa
> >> ge number=10000 severity=7 state=0 line=1 server=OpenClient text=Attempt
> to
> >> init
> >> iate a new SQL Server operation with results pending.
> >>
> >>
> >> FYI, this same code runs perfectly using dbd_freetds snapshot.  I am
> >> attempting to use freetds library since it seems to be under more active
> >> development and dbd_freetds seems to have a slight memory leak over long
> >> periods of time (weeks).
> >>
> >> Any info appreciated...
> >>
> >> Kevin
> >> Sofnet, Inc.
> >
> >---
> >You are currently subscribed to freetds as: kworm AT sofnet.com
> >To unsubscribe, forward this message to
> $subst('Email.Unsub')
> >
> >