FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Stefano Coletta [mailto:s.coletta AT uni.it]
> Sent: January 8, 2004 9:59 AM
>
> this is my first message in this forum.

Hello Stefano, welcome, and thank you for an excellent problem report.  

> 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. 
... 
> I've tested the Rows Affected property in Microsoft Access 
> Visual Basic 
> with an ADP project and it behaves correctly returning proper values.

(Do you mean ADO?)

> It seems to behave this way only with MERGE REPLICATION and not with 
> other types of replication.

It may be that the TDS stream is sending us a surprise from the downstream
database.  I can't think of any other reason that FreeTDS would react
differently to the two databases.  What you're doing is a little unusual; it
could well be that you're the first one to update a replicated database with
FreeTDS.  I suppose that's progress....

If you could, please post a TDSDUMP log of the failed transaction, so we can
analyze the packets.  I assume you're using TDS 7.0 or 8.0, for which the
log will not contain the login packet, so you don't have to worry about
exposing username/password information.  Please keep the session as brief as
possible.  

If the log is too large to post (>75 KB), it's better to make it available
on a website.  But if you can't do that, post it anyway, and I'll release
it.  It won't be *too* much bigger than that.  That can mean a delay of some
hours, however.   

If you can post a log before the weekend, perhaps we can incorporate a
remedy into the upcoming 0.62 release.  I'd like to see that.  The only
difficulty I foresee is that none of the developers has your particular
setup, so we'd be relying on you to test any potential fix.  

Regards, 

--jkl

> 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.
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.