Progress
Programming
Handbook


Trigger-based Replication Procedure

This section uses a simple one-way replication scheme to illustrate how to implement replication using Progress 4GL. In the description, the source indicates the database from which records are being transferred. The target is the database to which records are being transferred. Depending on the replication scheme, each database (or site) can fill the roles of source and target. Replication occurs record by record, and the source and target database tables must have identical field layouts.

Implementation of replication occurs in two stages:

  1. Logging changes to tables in a separate log table at the source database.
  2. Setting up a process to inspect the log periodically and replicate the data operations on the appropriate target databases.
Creating the Replication Changes Log

Create a database table to log changes for replication. Follow these steps to create the replication changes log:

  1. Using the Data Dictionary Tool, create a table with the fields shown in Table 11–2. (For the remainder of this procedure, this table is called Replog.)
  2. Table 11–2: Replication Changes Log Table Schema 
    Field
    Datatype
    Description
    TransactionID
    integer
    Represents a unique transaction number. This number is obtained through the DBTASKID function.
    TableName
    char
    Identifies the table to be changed.
    KeyValue
    char
    Represents a unique key value that identifies the corresponding record in the target database. Applies to deleted or modified records only.
    Event
    char
    Indicates that the record was created, deleted, or modified.
    DataRecord
    RAW
    Contains the created or modified record.
    LogDate
    date
    Standard date format.
    LogTime
    char
    String representing time.

  3. Select a table to be replicated.
  4. Using the Data Dictionary Tool, register database triggers REPLICATION–CREATE, REPLICATION–DELETE, and REPLICATION–WRITE for the selected table.
  5. These triggers will execute following the execution of any corresponding CREATE, DELETE, or WRITE trigger.

  6. In each of the trigger procedures, do the following to create a record to register the data change:
    • Identify the event and table (TableName and Event fields).
    • Use the DBTASKID function to get the transaction number (TransactionID).
    • Use the RAW–TRANSFER statement to move the record to the DataRecord field.

The following code example shows a generic trigger include file with trigger code:

/* Trigger Include File ’reptrig.i’ for replication*/ 
CREATE RepLog  
  ASSIGN  
   RepLog.TransactionID = DBTASKID(LDBDNAME(BUFFER {&RepLog})) 
   RepLog.TableName = ‘{&Table}’ 
   RepLog.KeyValue = ’{&Key}’ 
   RepLog.Event = ‘{&Event}’ 
   RepLog.LogDate = TODAY 
   RepLog.LogTime = TIME. 
  RAW-TRANSFER BUFFER {&Table} TO FIELD RepLog.DataRecord. 

TRIGGER PROCEDURE FOR REPLICATION-WRITE OF Customer OLD Buffer oldcust. 
{reptrig.i 
&Table = Customer 
&Key = STRING (oldcust.cust-num) 
&Event = WRITE} 

NOTE: More examples with sample source code can be found in DLC/src/prodict/rplctn.

Replicating the Data

A batch Progress client on the server machine monitors the replication changes log regularly and carries out replication. The batch Progress client transfers the data to the target database in a number of ways. In the simplest scenario, the batch client connects to the target database, reads the log, and executes a RAW–TRANSFER statement to transfer the data from the RAW DataRecord field to the target table on the target database.

If the connection to the target database is not feasible, one alternative is to dump pertinent log records to a text file and ship the file to the server machine. Then a monitoring batch client re-creates the log and transfers the data to the target database.

RAW-TRANSFER Statement

The RAW-TRANSFER statement allows you to transfer a record from a RAW field to a buffer, or from a buffer to a RAW field. You can also transfer directly from buffer to buffer. In 4GL replication, you use RAW–TRANSFER to move whole records to the RepLog and to move records from the log to the target database.

The following code example shows how you can use RAW-TRANSFER:

DEFINE VAR rvar AS RAW NO-UNDO. 
FOR EACH sourcedb.customer: 
  RAW-TRANSFER BUFFER sourcedb.customer TO FIELD rvar. 
  RAW-TRANSFER FIELD rvar TO BUFFER targetdb.customer. 
  RELEASE targetdb.customer.  
END. 

In this example, the first RAW–TRANSFER statement copies a record buffer in the source database to a variable of type RAW. The second RAW–TRANSFER statement copies the RAW field to the corresponding record buffer in the target database.

This replication could be written more efficiently as a buffer-to-buffer transfer, as shown in the following example:

FOR EACH sourcedb.customer: 
  RAW-TRANSFER sourcedb.customer TO targetdb.customer. 
  RELEASE targetdb.customer. 
END. 

For more information, see the entry for the RAW–TRANSFER statement in the Progress Language Reference .

DISABLE TRIGGERS FOR LOAD Statement

The DISABLE TRIGGERS FOR LOAD statement allows you to disable database triggers before replicating data. The following are reasons why you might want to include this statement in your code before executing the RAW–TRANSFER statement:

ALLOW REPLICATION Phrase

ALLOW-REPLICATION is an optional qualifier on the DISABLE TRIGGERS FOR LOAD statement. If ALLOW-REPLICATION is indicated, only CREATE, DELETE, ASSIGN, and WRITE triggers will be disabled. REPLICATION-CREATE, REPLICATION-DELETE, and REPLICATION-WRITE will execute when necessary.

This qualifier is useful, for example, in a cascading replication, where the target database is replicated to other targets in a cascading fashion. In this scenario, you might want to disable standard database triggers but allow replication triggers to fire in the target database table. This allows you to capture changes in the target replication log table.

Figure 11–1 shows an example of a cascading scheme. In this example, external data is received at one database, then replicated in a cascading series to other databases.

Figure 11–1: Cascading Replication

For more information, see the entry for the DISABLE TRIGGERS FOR LOAD statement in the Progress Language Reference .


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095