Re: Constant Update of SQl Server from an iSeries -- MIDRANGE-L

Subject: Re: Constant Update of SQl Server from an iSeries
From: "D*B" <dieter.bender@xxxxxxxxxxxx>
Date: Wed, 19 Nov 2014 13:27:07 +0100
List-archive: <http://archive.midrange.com/midrange-l/>
List-help: <mailto:midrange-l-request@midrange.com?subject=help>
List-id: Midrange Systems Technical Discussion <midrange-l.midrange.com>
List-post: <mailto:midrange-l@midrange.com>
List-subscribe: <http://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=subscribe>
List-unsubscribe: <http://lists.midrange.com/mailman/options/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=unsubscribe>

<Bor>
First, is trapping the changes. To me, journals are the only way to go.
</Bor>

it might depend on your needs. The diffrence comes up in case the connection between source and target breaks. Going the route via journal (to process the journal, you would have a NEP doing RCVJRNE) source and target will temporary go out of sync. Using triggers updates to the source system are impossible untill connection to the replicating system is possible.
For real synchronous replication you would have to use ArdGate or maybe DBGate (commercial), or infoSphere federation Server (very expensive) or one of the commercial proprietary solutions.

Dieter Bender

As an Amazon Associate we earn from qualifying purchases.

Follow-Ups:

Re: Constant Update of SQl Server from an iSeries , rob

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.