Pro2 replication schema triggers are used with the source OpenEdge Database. A schema trigger is a .p procedure that you add, through the data dictionary to the schema of a database. Schema trigger code defined in the OpenEdge Database is executed by database clients.

Pro2 replication triggers are used with the source OpenEdge database. You can use these triggers to:
  • Create the replication record based on the database, table, and ROWID.
  • Record the type of event (i.e. create, write, delete the transaction number).
  • Set the Applied flag to false (default).

Definition of the replication trigger in the schema of the tables to be replicated that indicates which procedure is to be run whenever there is a Create, Update, or Delete event on a record. In the OpenEdge database architecture, the triggers are executed by the client executable (versus the trigger being executed by the database server executable as in most other database systems).

The trigger procedure specified by the schema trigger definition. The Pro2 trigger procedures are very lightweight. They do not alter the application flow in any way and are transparent to both the application and the end-users.

In cases where replication triggers already exist in the source database for particular events and tables, the Pro2 replication logic needs to be integrated with or merged into the pre-existing triggers.

All replication triggers are compression triggers by default.
Note: You cannot use the compression trigger template when Auditing is implemented. You must override the default triggers.

Schema trigger definitions

Schema triggers are fired when schema-level objects (tables) are modified and when the user logon or logoff events occur. Some of these definitions are:
  • CREATE—To create and enable a database trigger.
  • DELETE—To remove a database trigger from the database.
  • WRITE—To write and edit a database trigger.
  • RE-DEL
  • RP-WRI
The event type RP-DEL stands for REPLICATION-DELETE and RP-WRI for REPLICATION-WRITE, includes both create and update events. The procedure specified is run when this type of event occurs. You can get a trigger definition report from the Procedure Editor (The Procedure Editor is an OpenEdge ABL code editor). Run Tools→ Data Administration. From the Data Administration window, select Database → Reports → Triggers

An example of the output from the Progress trigger report is shown below. This example is of a Customer table in the sports database after Pro2 triggers have been inserted:

Table 1. Progress trigger report
Table/Field name Event CRC Flags Procedure
CUSTOMER CREATE No C:\dlc101c\sports\crcust.p
DELETE No C:\dlc101c\sports\delcust.p
RP-DEL No .\bprepl\repl_d\dsports_Customer.t
RP-WRI No .\bprepl\repl_w\wsports_Customer.t
WRITE No C:\dlc101c\sports\wrcust.p

Alternatively, these trigger definitions can be displayed by the replTrigDisp.p procedure (to screen) and the replTrigDisp2.p procedure (to file).

Trigger procedures

The Pro2 trigger procedures are found by the client executable in a location specified in the PROPATH. The replication trigger location can be in the same directory as the other triggers (If there are other triggers defined for the database). However, these triggers must be already included in the PROPATH. You must take care to place the trigger procedures on the database server and on any application server boxes from which end users run the application.

Note that the pathname specified for the Pro2 replication triggers in the schema trigger definition is a relative path starting with bprepl. Typically, a bprepl directory is created with the following sub-directories in a location already in the PROPATH:
  • repl_d (delete triggers)
  • repl_w (write triggers)
In any alternate scenario, the PROPATH is modified to include the location of the bprepl directory.

When a replication trigger is defined in the schema for a table, the client attempts to run the specified trigger procedure. This happens when a client executable attempts to update a record in the source database.

The trigger procedures should be located on the database server if the user is connected as a local direct connect client (whether an end-user or an Progress Application Server servicing a remote client). Whereas, the trigger procedures should be on the client system if they are remote and are connected to the database via client/server.

For optimal performance, the replication triggers should be compiled (. r code). To compile the triggers, the standard OpenEdge application compiler is used in a Procedure Editor session connected to both the source database and the repl database.

Merged triggers

The Pro2 replication triggers need to be merged or integrated with the original triggers if the pre-existing replication triggers (REPLICATION-DELETE or REPLICATION-WRITE) exist in the source database. You can merge the triggers by adding a RUN statement in the original replication trigger procedure that calls the Pro2 trigger or by adding the Pro2 replication trigger logic to the original trigger.

Note:
The types of triggers in Progress are as follows:
  • Primary triggers—These types of triggers are not to be integrated with Pro2 triggers. CREATE, WRITE, and DELETE are primary triggers and are not impacted by Pro2 replication.
  • Replication triggers—These are executed after the primary triggers and need to be merged with the Pro2 triggers. These triggers are REPLICATION-DELETE or REPLICATION-WRITE.

Insert replication triggers

The replTrigInsert.p procedure is used to insert the triggers. This procedure is run from the OpenEdge procedure editor connected to both the source database and the repl database (or to the source database with the embedded repl tables). Perform the following steps to insert replication triggers:

  1. Shut down all the database instances and PAS instance prior to inserting the replication triggers.
  2. Navigate to the \db folder of Pro2 from the Windows Explorer ( for example, C:\Pro2v60\db).
  3. Create a new folder named bprepl in the db folder.
  4. Navigate to the \bprepl folder in the Pro2 folder (C:\Pro2v60\bprepl) and copy the following folders:
    • repl_d
    • repl_w

    These folders contain the replication triggers and are required to process the replication queue records (also known as replQ records).

  5. Paste the folders in the \db\bprepl folder of Pro2 (C:\Pro2v60\db\bprepl).
  6. Type prowin -db sports -db repl and click Enter. The Procedure Editor window appears. This will insert replication triggers in the source database (sports).
  7. Open the ReplTrigInsert.p file from C:\Pro2v60\utils in the Procedure Editor window.
  8. Enter the name of the source database (sports). Close the Procedure Editor window.
  9. Restart all the database instances and the PAS instance.

Remove replication triggers

The replTrigDel.p procedure is used to delete the replication triggers. This procedure is run from the OpenEdge procedure editor connected to both the source database and the repl database (or to the source database with the embedded repl tables). Perform the following steps to delete replication triggers:
  1. Shut down all the database instances and PAS instance prior to deleting the replication triggers.
  2. Navigate to the \db folder of Pro2 from the Windows Explorer ( for example, C:\Pro2v60\db).
  3. Create a new folder named bprepl in the db folder.
  4. Navigate to the \bprepl folder in the Pro2 folder (C:\Pro2v60\bprepl) and copy the following folders:
    • repl_d
    • repl_w

    These folders contain the replication triggers and are required to process the replication queue records (also known as replQ records).

  5. Paste the folders in the \db\bprepl folder of Pro2 (C:\Pro2v60\db\bprepl).
    Note: Ignore steps 4 and 5 if the triggers are already added in the \db\bprepl folder.
  6. Type prowin -db sports -db repl and click Enter. The Procedure Editor window appears.
  7. Open the ReplTrigDel.p file from C:\Pro2v60\utils in the Procedure Editor window.
  8. Enter the name of the source database (sports). Close the Procedure Editor window.
  9. Restart all the database instances and the PAS instance.
Note: Running the replTrigDel.p does not delete the trigger procedures. Once the trigger definitions are removed, the trigger procedures wont be executed even if they remain in the system.