FreeTDS Development Group

["Geoff Winkless" <geoff AT farmline.com>]

Hmm I found the message I was thinking of...

On Friday, December 24, 1999 1:00 AM, "Kevin Wormington" <kworm AT sofnet.com>
wrote:
Subject: [freetds] Re: DBD::Sybase-0.21 and latest CVS snapshot
> I have been using a 0.47 snapshot with DBD::Sybase-0:20 and 0:21 with
great
> success going against MS-SQL 7 servers.  I use it for radiator radius and
> the only problem I have seen is a very slow memory leak, which is why I
> thought I would try a later 0.50 snapshot.  The snapshot will compile fine
> but the following select returns some strange characters keeping radiator
> from operating correctly.  Here is the perl snippet :
>
>
>     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)
>     {
>     $self->log($main::LOG_INFO,"$cust_id, $password, $username, $timeleft,
> $blockuser");
>     $sth->finish;
>      }
>
>
> Here are the results of the above self->log printout:
>
> Thu Dec 23 17:48:03 1999: INFO: 1074, jaw^@, jaw^@, ,
>
>
> As you can see there are some "^@" after each field.  Any help would be
> greatly appreciated. Also, I have tried it with tdsver=4.2 and 7.0 and
with
> DBD::Sybase 0.20 and 0.21.


"Brian Bruns" <camber AT umcc.ais.org> replied on 29 December 1999
> Anyway, I just checked some code in to correct this.  Both PHP and
> DBD::Sybase should work now :-). I didn't completely support every
> possible permutation of this thing, but it goes something like this:
> tds_convert() returns the length *including* the null. _ct_bind_data()
> looks at the format and there is a switch statement where if its
> CS_FMT_UNUSED the length is reduced by one, which is fine since the rest
> of the buffer is undefined anyway. CS_FMT_NULLTERM is the default case so
> nothing needs to be done for that. CS_FMT_BLANKPAD and CS_FMT_NULLPAD
> should be added to that switch with the appropriate action (just didn't
> feel like getting into it tonight...highlander (the movie) is on and I'm
> going to go watch it).  dblib should also be retrofited for
> STRINGBING/NTBSTRINGBIND stuff as well so it is all handled the same.


Kevin intimated that this had fixed his problem.

Is this an instance of the same problem rearing its head?

Geoff