[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dbintegrator_public_public

Title:DB Integrator Public Conference
Notice:Database Integration - today! Kit/Doc info see note 36
Moderator:BROKE::ABUGOV
Created:Mon Sep 21 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1171
Total number of notes:5187

1078.0. "Replicate a huge RMS file to a DB???" by ORAREP::HGOVC::PATRICKNG () Tue Jul 09 1996 23:34

    Hi,
    
    Is there any tool in the market that replicates modified records in a
    huge RMS file to a text file or to a database?
    
    How can I replicate a huge RMS file on OpenVMS 6.0/6.1 to a SQL Server 6.5
    on Windows NT? This replication process runs every 1-2 hours or even
    less. Copying whole file to SQL Server is impossible because the down
    time of both applications and the traffic on the network.
    
    Assume no application modify is needed. The application has been
    written over 10 years and noone understands the logic.
    
    Any recommendation is welcome.
    
    Thanks,
    Patrick
T.RTitleUserPersonal
Name		DateLines
1078.1Not reallysvrav1.au.oracle.com::MBRADLEYI was dropped on my head as a baby. What's your excuse?Wed Jul 10 1996 01:2623
Patrick,

The only replication of RMS files that I know of is in the Rdb Replication 
Option (formerly Data Distributor). But for RMS files as a source, this 
will copy the complete file every time the transfer runs.

An alternative would be to keep a local copy of the rms file that was in 
synch with the SQL server copy, and write a program.

For example lets call the source rms file A and the target SQL server file 
B. We first off copy A to B and at the same time make another copy call it 
C on the system where A is.

I can then write a program that reads both A and C in some predefined order 
looking for differences. The differences can then be applied to both B and 
C.

Of course this means that you have to read all of A each time, but at least 
you don't have to copy it across the network.

Cheers,

Mark.
1078.2Agree with .1 - Not reallyBROKE::ABUGOVWed Jul 10 1996 09:5513
    
    Hi Patrick,
    
    I'd echo Mark's response.  The replication option will do all or
    nothing.
    
    There might be ways to accomplish replication using some application logic
    and adding timestamp fields, but it sounds like this is out of the question.
    
    Sorry,
    
    Dan
1078.3Jon Bauer might know somethingBROKE::PROTEAUJean-Claude ProteauWed Jul 10 1996 17:1912
    
    Jon Bauer was working on a tool that might do this, but I've no idea if
    it (a) is in some completed state and (b) what kind of performance one
    might expect.  The problem with replicating only changes from an RMS
    file is that someone has to figure out what changed.  If the
    application was designed in such a way that that type of information
    could be detected, sure one could do this.  Odds are this isn't the
    case.  So a binary compare has to be done with the current data in the
    source RMS file and the current data in the target file or database. 
    That is what Jon's stuff does or did (among other options).
    
    Claude