Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Replication Error

3 posts in Replication Last posting was on 2006-11-18 09:58:30.0Z
"Mike Wilcock" <mike.wilcock Posted on 2006-11-17 17:24:20.0Z
Reply-To: "Mike Wilcock" <mike.wilcock@<nospam>stanfordtec.co.uk>
From: "Mike Wilcock" <mike.wilcock@<nospam>stanfordtec.co.uk>
Newsgroups: Advantage.Replication
Subject: Replication Error
Date: Fri, 17 Nov 2006 17:24:20 -0000
Lines: 22
Organization: Stanford Technologies Limited
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.2663
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 91.84.24.61
Message-ID: <455dee8b@solutions.advantagedatabase.com>
X-Trace: 17 Nov 2006 10:16:59 -0700, 91.84.24.61
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!91.84.24.61
Xref: solutions.advantagedatabase.com Advantage.Replication:138
Article PK: 1133995

Hi,

I'm trying to enable two way replication between two ads servers which are
at remote locations and connected via a vpn. At the moment I'm just
experimenting so for testing purposes I have created a single cdx table and
indeces and the two data dictionaries at either end are identical.
Eveything works fine, but I'm now at the stage where I want to test an ON
CONFLICT trigger.

If I pull the lan cable out of the back of the server and make changes, all
changes get written to the replication queue and are then processed when the
lan cable is plugged back in, this works fine. However, if I edit the same
record at both ends then plug the cable back in the changes get stuck in the
queue and the ads_err table reports a 7137 error at both ends.

Anyone have any ideas?



Mike


Peter Funk (ADS) Posted on 2006-11-17 18:00:14.0Z
Date: Fri, 17 Nov 2006 18:00:14 +0000 (UTC)
Message-ID: <864d0bcb701f8c8d84eb1b468a6@devzone.advantagedatabase.com>
From: Peter Funk (ADS) <pfunk@nospam.com>
Subject: Re: Replication Error
Newsgroups: Advantage.Replication
References: <455dee8b@solutions.advantagedatabase.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 936.5
NNTP-Posting-Host: 10.24.38.115
X-Trace: 17 Nov 2006 10:56:00 -0700, 10.24.38.115
Lines: 24
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.38.115
Xref: solutions.advantagedatabase.com Advantage.Replication:139
Article PK: 1133996

Hello Mike,
The 7137 error indicates that the target server found zero or muliple records
in the table to update (it should always find one, and only one record).
In your case, I'd guess it found zero records. This is probably because
the update(s) you made to the record (while the cable was unplugged) caused
the record to not pass the replication filter when the replication update
ran. IOW, based on the row identification method you setup in the publication,
the target server was unable to locate the record that was updated on the
source server. If you chose the "all colums" option as the row identification
method, then changing any field in the target record while a replication
update is pending will cause the 7137 error. If you expect the same record
to be changing at both sites, you need to either use the "primary key" row
identification method, or use a subset of the "all columns" method where
the columns you choose don't change.

Keep in mind the ON CONFLICT trigger will only fire if the target record
is found, and it is not the same as the source record (before the update
began). If the target record is not found, there can be no conflict.

HTH,
Peter Funk
Advantage R&D


"Mike Wilcock" <mike.wilcock Posted on 2006-11-18 09:58:30.0Z
Reply-To: "Mike Wilcock" <mike.wilcock@<nospam>stanfordtec.co.uk>
From: "Mike Wilcock" <mike.wilcock@<nospam>stanfordtec.co.uk>
Newsgroups: Advantage.Replication
References: <455dee8b@solutions.advantagedatabase.com> <864d0bcb701f8c8d84eb1b468a6@devzone.advantagedatabase.com>
Subject: Re: Replication Error
Date: Sat, 18 Nov 2006 09:58:30 -0000
Lines: 40
Organization: Stanford Technologies Limited
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.2663
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 91.84.8.228
Message-ID: <455ed7b2@solutions.advantagedatabase.com>
X-Trace: 18 Nov 2006 02:51:46 -0700, 91.84.8.228
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!91.84.8.228
Xref: solutions.advantagedatabase.com Advantage.Replication:141
Article PK: 1134000

Hi Peter,

Everything now replicates as expected. Thanks for the explanation.


Regards,


Mike

"Peter Funk (ADS)" <pfunk@nospam.com> wrote in message
news:864d0bcb701f8c8d84eb1b468a6@devzone.advantagedatabase.com...
> Hello Mike,
> The 7137 error indicates that the target server found zero or muliple
> records in the table to update (it should always find one, and only one
> record). In your case, I'd guess it found zero records. This is probably
> because the update(s) you made to the record (while the cable was
> unplugged) caused the record to not pass the replication filter when the
> replication update ran. IOW, based on the row identification method you
> setup in the publication, the target server was unable to locate the
> record that was updated on the source server. If you chose the "all
> colums" option as the row identification method, then changing any field
> in the target record while a replication update is pending will cause the
> 7137 error. If you expect the same record to be changing at both sites,
> you need to either use the "primary key" row identification method, or use
> a subset of the "all columns" method where the columns you choose don't
> change.
>
> Keep in mind the ON CONFLICT trigger will only fire if the target record
> is found, and it is not the same as the source record (before the update
> began). If the target record is not found, there can be no conflict.
>
> HTH,
> Peter Funk
> Advantage R&D
>
>