Article View: borland.public.interbase.replication
Article #722N-Way replication problem
From: Mike Senkovich
Date: Wed, 17 Oct 2001 22:29
Date: Wed, 17 Oct 2001 22:29
47 lines
3106 bytes
3106 bytes
Hello all. I'm having some problems getting the N-Way replication scenario to work. For now I am testing this with 2 DBs. When I get it to work with these 2, I will try it with 3. Using the "Preventing Rows from bouncing back in an N-Way model" section of the Internals doc as a guide, I have created 2 Replication schema: Schema 1: Source-to-Target (similar to Chicago-to-New York) Source DB -- Replication User Name is REPL1 (similar to REPL_CHICAGO) Target DB -- Replication User Name is REPL Schema 2: Target-to-Source (similar to New York-to-Chicago) Source DB -- Replication User Name is REPL Target DB -- Replication User Name is REPL1 Also, in the Target DB, I added the following Row Level condition in the tables I am replicating: USER <> 'REPL1' The idea is that I want the Source DB to be able to replicate its changes to the Target DB, the Target DB to replicate it's changes to the Source DB, and I don't want the Source DB data that was already replicated to the Dest DB to be replicated back to the Source DB. Note that I will be adding other Source DBs, so just using the REPL user by itself won't help me. I create a single record in the same table in each database (each with a unique primary key). I click the replication button and in this first pass the source and dest values replicate correctly (both source-to-target and target-to-source), but there are still values in the Repl_Log on the Source side. So I click the replication button again, and it replicates what's in the Repl_Log table. The result is a "Primary Key Violation - Converted to UPDATE STATEMENT in the LOG file" because these values have already been replicated in the 1st pass. 1) Why is replication of the same data happening twice? 2) Do I have the User Names or Row Level conditions in each schema set up incorrectly? I am using the IB5 Replication server. The source and target DBs have identical metadata (except for what the Replication manager has added). The DBs also have permissions granted on all tables for users REPL and REPL1. Thanks in advance for any help you can provide. -Mike
Technical Details
Message-ID:
<3bce065e_2@dnews>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.wirehub.nl!news-out.nuthinbutnews.com!propagator2-austin!propagator!feed2.newsfeeds.com!newsfeeds.com!news-in-austin.nuthinbutnews.com!intgwlon.nntp.telstra.net!newsfeeds.ihug.co.nz!ihug.co.nz!dnewsShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f89d7,c97d7c2a6e480391,start X-Google-Attributes: gidf89d7,public X-Google-ArrivalTime: 2001-10-17 15:34:23 PST From: "Mike Senkovich" <mikes@decisionsys.com> Newsgroups: borland.public.interbase.replication Subject: N-Way replication problem Date: Wed, 17 Oct 2001 17:29:10 -0500 Lines: 49 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 NNTP-Posting-Host: 12.106.6.25 Message-ID: <3bce065e_2@dnews> X-Trace: dnews 1003357790 12.106.6.25 (17 Oct 2001 15:29:50 -0700) Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.wirehub.nl!news-out.nuthinbutnews.com!propagator2-austin!propagator!feed2.newsfeeds.com!newsfeeds.com!news-in-austin.nuthinbutnews.com!intgwlon.nntp.telstra.net!newsfeeds.ihug.co.nz!ihug.co.nz!dnews