FreeTDS Development Group

[Stefano Coletta <s.coletta AT uni.it>]

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