[freetds] New BUG: update/delete returns -1 instead of correct
affected rows on Merge Publication on MSSQL 2000 SP3a
Stefano Coletta
s.coletta at uni.it
Thu Jan 8 15:58:32 EST 2004
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
More information about the FreeTDS
mailing list