Help SQL Replication

Enhancing data by using stored procedures or SQL statements

When you define subscription set information, you can also define run-time processing statements by using SQL statements or stored procedures that you want the Apply program to run every time it processes a specific set. These run-time processes enable data manipulation during replication.

Such statements are useful for pruning CCD tables and controlling the sequence in which subscription sets are processed. You can run the run-time processing statements at the Capture control server before a subscription set is processed, or at the target server before or after a subscription set is processed. For example, you can execute SQL statements before retrieving the data, after replicating it to the target tables, or both.

Restriction for nicknames: Federated DB2® tables (which use nicknames) are usually updated within a single unit of work. When you add an SQL statement to a subscription set that runs after the Apply program applies all data to the targets, you must precede that SQL statement with an SQL COMMIT statement in either of the following two situations: The extra COMMIT statement commits the Apply program's work before it processes your added SQL statement.

Stored procedures use the SQL CALL statement without parameters. The procedure name must be 18 characters or less in length (for System i®, the maximum is 128). If the source or target table is in a non-DB2 relational database, the SQL statements are executed against the federated DB2 database. The SQL statements are never executed against a non-DB2 database. The run-time procedures of each type are executed together as a single transaction. You can also define acceptable SQLSTATEs for each statement.

Use the ASNDONE exit routine if you want to manipulate data after processing of each set completes (rather than after processing of a specific set completes).



Send your feedback | Information roadmap | The Q+SQL Replication Forum

Update icon Last updated: 2013-10-25