Skip to Content.
Sympa Menu

freetds - [freetds] New BUG: update/delete returns -1 instead of correct affected rows on Merge Publication on MSSQL 2000 SP3a

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Stefano Coletta <s.coletta AT uni.it>
  • To: freetds AT lists.ibiblio.org
  • Subject: [freetds] New BUG: update/delete returns -1 instead of correct affected rows on Merge Publication on MSSQL 2000 SP3a
  • Date: Thu, 08 Jan 2004 15:58:32 +0100

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






Archive powered by MHonArc 2.6.24.

Top of Page