🚀 go-pugleaf

I discovered that if I change the Table Settings of any of the tables, I
need to remove and create the system objects in the source database.  That
will update the triggers in the Source and Target DBs with the correct "IF"
tests.

However, I have done this and things are still not working as I expect.

The "After Insert" system triggers for the source table is:
CREATE TRIGGER REPL$BID521_I_27_6 FOR BID
ACTIVE AFTER INSERT POSITION 32767
AS BEGIN IF (USER <> 'REPL') THEN BEGIN   INSERT INTO
REPL_LOG(REPLNO,PUBDBNO,SUBDBNO,RELATIONNO,REPTYPE,NEWKEY)
  SELECT REPLNO,PUBDBNO,SUBDBNO,RELATIONNO,'I',NEW.BIDKEY
    FROM REPL_SEPARATOR
   WHERE REPLNO=27
     AND PUBDBNO=6
     AND RELATIONNO=521;

END
END
 ^
The "After Insert" system trigger for the Target table is:
CREATE TRIGGER REPL$BID583_I_28_7 FOR BID
ACTIVE AFTER INSERT POSITION 32767
AS BEGIN IF (USER <> 'REPL') THEN BEGIN
IF (USER <> 'REPL1') THEN BEGIN

  INSERT INTO REPL_LOG(REPLNO,PUBDBNO,SUBDBNO,RELATIONNO,REPTYPE,NEWKEY)
  SELECT REPLNO,PUBDBNO,SUBDBNO,RELATIONNO,'I',NEW.BIDKEY
    FROM REPL_SEPARATOR
   WHERE REPLNO=28
     AND PUBDBNO=7
     AND RELATIONNO=583;
END

END
END
 ^

Replicating a single record from the target table to the source (New York to
Chicago) results in the record in REPL_LOG, which means it will be
replicated back to the Target DB on the next replication execution.

What am I missing?  The replication USER can only be REPL or REPL1.  My
application is logged in as a different IB user (MYLOGIN).  Does my
application need to be using the REPL1 IB login too?

Thanks
-Mike

"Mike Senkovich" <mikes@decisionsys.com> wrote in message
news:3bce065e_2@dnews...
> 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
>
>