Bearing in mind previous responses, it's important to know how
accurate the image on the remote system has to be and what purpose
it's required for.
If it's required to establish an audit trail or has to be an absolute
image or the transmission protocol has to be difficult/impossible to
manipulate then a remote journal solution seems more appropriate.
If it's an application thing and you can handle the occasional hiccup
then any variation on DDM/Remote Dataqueues/Triggers seems reasonable.
In this scenario I'd probably go with a trigger on the local file and
a DDM data queue.
You did say replication, so if you're doing UPDATES and DELETES as
well as INSERTS the logic to handle processing for this particular
file will get closer to that for processing remote journal entries
than you think (at least I think it will).
The likelihood of another table being added once this one is done is
also important as any code developed for receiving and applying
journal entries is likely to be easier to apply to different tables
better than code to update a specific table.
In terms of a cheaper entry point than I seem to remember that
TAATOOLS had a command that would help with scraping remote journals
so that might be a more economic approach.
On Fri, Jan 7, 2011 at 8:55 AM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:
Have a file that I need to replicate in near real time to another
system. What techniques do folks use? I'm thinking of triggers on the
from file, remote SQL connect, ACD as appropriate. I guess journaling
would be an option too. Opinions welcome. Thanks...
midrange.com
