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:
Creating the Replication Changes Log
Create a database table to log changes for replication. Follow these steps to create the replication changes log:
- 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.)
- Select a table to be replicated.
- Using the Data Dictionary Tool, register database triggers REPLICATION–CREATE, REPLICATION–DELETE, and REPLICATION–WRITE for the selected table.
These triggers will execute following the execution of any corresponding CREATE, DELETE, or WRITE trigger.
- In each of the trigger procedures, do the following to create a record to register the data change:
The following code example shows a generic trigger include file with trigger code:
NOTE: More examples with sample source code can be found inDLC/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:
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 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:
- Replication in Progress is based on the original scope of the transaction. If the database trigger code in the source database changes data in other tables, those other tables can also participate in replication. Using DISABLE TRIGGERS FOR LOAD allows the replication process itself to keep the database records consistent.
- In a two-way replication scheme (peer-to-peer model) DISABLE TRIGGERS FOR LOAD prevents a target database from creating a record of a change generated by the replication itself. This would result in changes being replicated back and forth between databases.
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 |