🚀 go-pugleaf

Is this a one way replication? Ie are you only moving data from the source 
to the tartget. Is everything happening at the source and the target is in 
essence a backup copy? I'd suggest looking at changing the scheme so that it 
is not a TimeStamp resolution and change it to master > slave if this is the 
case. That should get round the time stamp issue.


"MC" <mwongxn@yahoo.com> wrote in message 
news:41ab4e3b@newsgroups.borland.com...
> Hi everyone,
>
> I have a problem with Replication Manager that's bundled with IB7.01 and
> would appreciate any advise from anyone here.
>
> Scenario:
>
> I've 2 databases (one SOURCE and one TARGET).
> IB Replication has been setup and at every 180 mins (3 hours) interval, 
> the
> new and updated records will get replicated from the SOURCE to TARGET DB.
> Any changes made in the SOURCE DB will be stored in the REPL_LOG table and
> once the replication is completed, the REPL_LOG Table will be empty.
>
> Problem:
>
> Recently, I noticed that when I do a "select count(*) from REPL_LOG",
> there's a value of 63315.  Meaning that there are 63k+ records in the 
> SOURCE
> DB that's not replicated to the TARGET DB.
>
> I used the 'Manual Conflict Resolution' tool, that's part of the 
> Replication
> Manager, and found that there're 2 types of an error for all these 
> records;
> Error:
> 1) "Can't Insert: Row exists with NEWER TimeStamp - MANUAL RESOLUTION
> REQUIRED"
> 2) "Can't Update: Row exists with NEWER TimeStamp - MANUAL RESOLUTION
> REQUIRED"
>
> This issue has caused the data on both DB to be different.
>
> Question:
>
> Is there anyway that I can use to force the 63k+ records to be replicated
> over to the TARGET DB??
>
> Please advise.
>
> Thank you and Regards,
> MC
>
>