FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

On Thu, 8 Jan 2004, Stefano Coletta wrote:

FYI I'm going to try and reproduce this one.. It pry has something to do
with extra data returned from the triggers.  I'd try the snapshot
replication instead.

Have Fun!
Peter

> Hello there,
> this is my first message in this forum.
>
> I'm almost sure to have found a bug in the freetds lib (even 0.62rc3)
> that occurs only when I try to do an update or delete against Microsoft
> SQL Server 2000 SP3a while the database is in Merge Replication. The
> problem arises when I try to read the "rows affected" property which
> returns always -1 instead of the correct number of affected rows. Even
> if this seems not to be a serious bug it has some serious implications
> when used in conjuction with a software like Radiator (an excellent
> Radius deamon). In fact Radiator relies on Rows Affected values for
> certain operations. To workaround this problem we have modified the
> source code of Radiator to not rely on Rows Affected property, but this
> may not be so easy to achieve for Closed source software or complex ones.
>
> I've tested the Rows Affected property in Microsoft Access Visual Basic
> with an ADP project and it behaves correctly returning proper values.
>
> To reproduce the problem:
> Create two databases with one table and some data (identical).
> The first database should be published with a Merge Replication method
> on another server.
> The second database is to be left alone on a single server.
> Then run a perl script like this:
>
> #!/usr/bin/perl
>
> use DBI;
> $ENV{'SYBASE'} = '/usr/local/';
>
> $dbh = DBI->connect('dbi:Sybase:server=srvname', 'login', 'password');
>
> #This is a DB WITH Merge Replication
> $dbh->do("use merged-dbname");
>
> #This is a DB without Merge Replication
> #$dbh->do("use simple-dbname");
>
> $sth = $dbh->prepare("update TABLENAME set FIELD=VALUE where CONDITION")
> or die 'prepare';
>
> CHECK THIS VALUE: sth->rows
>
> $sth->finish;
> --------
>
> Swap the database name with the NOT replicated DB and with the
> REPLICATED DB to see the results of update/delete statements.
>
> In the NOT replicated DB the rows returned are correct while in a
> REPLICATED DB rows is -1 or other odd values.
>
> You can try to use other languages or interfaces that are using freetds
> and you'll got similar results.
>
> For example, I've tried even with a Perl ODBC connection instead of
> Sybperl and I got "0E0" instead of "-1".
>
> I'm not pretty sure if this is a FreeTDS bug or something else but right
> now I've no time to investigate further.
> I'm quite sure that it is not a Radiator bug.
>
> It seems to behave this way only with MERGE REPLICATION and not with
> other types of replication.
>
> It even seems not to be a Microsoft bug because by means of Visual Basic it 
> works.
>
> --
> Stefano Coletta
>
> Unidata S.p.a.
> Via Portuense, 1555 - 00050 Roma ( Ponte Galeria )
> Tel +39 06650951
> Fax +39 0665095002
> E-mail s.coletta AT uni.it
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>