Unzip the zip file. It contains the following files
  - rmgr.exe       (The replication Setup Tool or Manager)
  - replicate.exe  (The replication daemon)
  - ibdcc.dll      (dll used within replicate.exe)
  - replicate.gbk  (backup of empty replicate.gdb ) 
  - repltrig.sql    ( Used by rmgr.exe.  Must be located in the 
                      same as replicate.gdb )
  - repl.ini       ( Used by both exes)
    The replication manager program updates
    this file.  The replication daemon reads/updates
    this file as well. This ini file must be located in a
    directory within the exes Windows search PATH.
    A brief description of the three sections that must be
    contained within repl.ini follows:
     
    [Paths]- used by rmgr.exe to store a history of 
    recently used replication db path names.

    [ReplServer] - Configuration parameters read/updated by
    the replication server process. "Interval" represents the
    numbers of seconds to "sleep" before polling for any 
    changes. "EventResp" is a boolean used to indicate whether
    the Replication Server process should respond to events
    initiated by changes that have occurred.  EventResp should
    only be True if your tx volume is small and the databases
    are located locally on same machine or LAN.

    [ReplMgmt] - PATH indicates where the Replication
    server process can expect to find the replication db and
    other necessary files.
    i.e. replicate.gdb.  

  - iblogo.bmp     (*.bmp and ibdc.dll are used by replicate.exe 
                    and must located in the same directory as 
                    the exe)
  - slight.bmp,rlight.bmp, ylight.bmp, glight.bmp, replsvr.bmp
  - readme.txt  ( You're reading it )
  - repl.doc  ( Provides an overview of architecture)
  
Overview:

The replication system consists of at least 3 databases 
and 2 applications.  The at least 3 databases are a 
replication management database (replicate.gdb), a 
replication source database and n target database.  
The Manager application "rmgr.exe" performs the tasks required
to setup replication.  The Replication Server "replicat.exe" 
performs the actual replication from the source to target 
databases.

Step:

1)  Use "gbak" (or the IB Server Manager) to restore 
    "replicate.gbk" and create the replication management 
    database "replicate.gdb". (If using "gbak", check to make 
    sure the PATH for the database is accurate for your 
    system.)

2)  Modify the repl.ini file.  Modify the "Path" variable under
    the [ReplMgt] section to specify the path in which you created
    replicate.gdb (in Step 1).  e.g. if you created
    replcate.gdb file in a directory called c:\ibserver, the script
    would have created replicate.gdb in "c:\ibserver".  Therefore,
    your repl.ini section should look as follows:
  
    [ReplMgmt]
    Path=c:\ibserver

3) Overview of Replication Mgr

The replication manager (RMGR.EXE) provides the management interface to the 
replication services provided by REPLICAT.EXE.  With the replication manager, 
one can:
a) specify the tables to be replicated. 
b) specify the columns in each table to be replicated
c) specify the UNIQUE integer key that identifies rows within each able
d) (optionally) build an ISQL script to create the triggers necessary to replicate each table
e) specify the path to the target databases
f) specify which tables are to be replicated to which target databases
g) build an ISQL script to create the trigger that posts event alerters whenever a table to be replicated is changed.

When a user enters this information, the replication manager saves it to
the database "replicate.gdb" as well as special tables in the source database.

Running RMGR.EXE

AN IMPORTANT NOTE ABOUT USER NAMES:  The USER names and passwords entered 
when selecting source and target databases with the Replication Manager 
(RMGR.EXE) will also be used by the Replication Server when it performs 
replication.  It is important to note that, by default, changes initiated 
by the user name that is specified when using RMGR.EXE to log into 
the source database are not replicated.  For example, if one logs into the 
Source DB as "SYSDBA", then changes made by any user logged in as "SYSDBA" 
will not be replicated.  This is to stop changes made by the replication 
server from begin replicated in a circular infinite manner.

It is recommended that a replication specific user account (REPL perhaps) be 
setup to avoid conflicts with SYSDBA.  The Replication Server and, therefore, 
this account, must have select access to all replication source tables in 
the source database and select, insert, update and delete access to all target 
tables in the target database.  Practically speaking, you'd probably just 
want to GRANT ALL TO REPL.  If NOBODY EVER modifies data using the
SYSDBA account, then one could use SYSDBA as the replication account.  If 
one does not anticipate two-way replication (hence, circular inifinite 
replication is not possible), then the trigger generation template can be 
modified to allow all changes to be replicated (see step 4. below for more 
information).


1)  The "Open DB" button selects the source database.  Upon opening the
source database, it's path is displayed in the box underneath the Open/Close
buttons.  Once a source database has been selected, all subsequent operations
apply to it.  

The first time a database is selected as the source, it will not contain the 
replication management tables ("changes", "repl_tables").  If these tables 
are not found, the program will tell you that the database "is not setup
for replication" and ask you if you want to add them.  Upon selecting "OK", the
program will add these tables to the source database and grant to public the 
following access permissions: changes: select/insert, repl_tables: select.

2)  Select a table to be replicated from the "Table Name" combo box.  Once
the source table has been selected, all subsequent operations apply to it.
Make sure you use the drop down arrow to Select the table.

3)  The "Columns" tab allows users to select the columns from the selected
table to be replicated.  Click the "Modify..." button to select columns to
be replicated.  THE FIRST COLUMN SPECIFIED MUST BE AN UNIQUE INTEGER KEY.
To stop replicating a table, don't specify any columns to be replicated.
NOTE:  Computed fields and columns containing array data are not displayed
because they cannot be replicated. Press OK.  The fields selected should
now be under the Replicated Columns Heading.  Press Save to the Save button after you've
selected the columns you want to replicate.

4)  The "Triggers" tab creates an ISQL script to build the triggers required
to replicate the specified table.  The user must specify the columns to be
replicated via the "Columns" tab prior to selecting "Triggers".

You may edit the triggers created (at your own risk).  Clicking "Save" will
prompt for a file name in which to save the trigger.  The "ApplyDB"
button will automatically apply the triggers to the source DB.

The file "repltrig.sql" contains the trigger generation template.  At your own
risk, you may edit this file to change the basic format of the triggers that
are generated.  For example, if you want all replication triggers triggers to 
fire at a specific position, you could specify a trigger position number in
"repltrig.sql" rather than editting each generated trigger.  Another example,
is if one wants to remove the check to stop circular replication.  In this
case, one would modify the template to remove the line:
"if ( USER <> @@username@@ ) then" and its related syntax. 
The exact details of this file are explained more fully in its header.

5)  The "Target DBs" tab allows the user to specify target databases and
to specify which targets are to receive the selected table.  Click the 
"Add DB..." to create a target database entry.  Click the "Modify..." button
to specify which targets are to receive the currently selected table.
YOU CANNOT DELETE TARGET DBS.  To stop replicating a table, don't specify 
any target dbs.

6)  The "Events" tab creates an ISQL script to build a trigger that will
post an event alerter whenever a replicated table changes.  "Checking" the
"Event Driven Replication" box builds the trigger to post the event alerter.
"Unchecking" the box builds a SQL statement to drop the trigger.

Your source database is ready to replicate!



Running replicat.exe:

Once Steps 1-6 from above have been completed, the 
replication daemon can be started.  This daemon can propagate
changes in three ways: ( or any combination of the three).
EventBased, TimeBased, manually initiated.  See the Properties
section under the Options section of the Main Menu to configure
these options.

Caveats:

  - Does not support Array datatype.
  - Errors which occur as part of the replication run
    are logged to a file called repl.err
    It is located in the directory specified in the Path variable
    within the ReplMgmt section of the repl.ini file.
  - The exes are dependent on the Windows32 dll RASAPI32.DLL
    It's available on win95 and WinNT Server. It is NOT available
    on WinNT Workstation.
