Child Tables

Data models typically contain tables that share column data through a relationship. You can configure a publishing table to include related data from another table for publication. When rows are inserted into the publishing table, a message that includes the data from the source table and related (child) table is published.

Data from the related table is not copied to the publishing table, but is fetched by reference. On the Subscriber endpoint, a corresponding table with the same columns as the child table associated with the publishing table must be specified.

Any change to a child table without a change in the parent table is not processed. The adapter only monitors changes in the parent table for publication. The adapter updates the child rows by deleting all the related child rows and then inserting child rows again based on the data in the received message.

Restrictions of Child Tables

Parent and child tables have to comply with restrictions so that messages can be transferred between Publication Service and Subscription Service.

The restrictions are listed as follows:
  • The child table in the source database and child table in the destination database must have the same columns, but the table names can be different. If the child table associated with the publishing table and the child table associated with the destination table have different names, you must set a mapping between the child tables when configuring Subscription Service.
  • When parent-child relationships are defined, Subscription Service must use the same repository as Publication Service.
  • When working with parent-child tables, it is good practice to set the ADB_OPCODE property in the parent table and child table to the same value. Or you can just set the ADB_OPCODE property in the parent table and leave the ADB_OPCODE property in the child table empty.