When you create tables for change capture, you map paths by selecting a starting record in the subschema and navigating set relationships to the final target record for change capture.
The set navigation path in the mapping must be from owner to member records only. The correlation service is limited to navigating up owner chains when gathering related information.
Only changes to the final record in the path are captured. Changes to any other record in the path are ignored unless you map a separate table to capture changes to that record. However, mapping related records is required when fields in those records provide context to changed records in the database schema. For example, if a CA-IDMS schema contains salary records that are related to employee records by a set, to insert an instance of the SALARY record for a specific employee would require the employee ID in the EMPLOYEE record to be included in the message sent by the distribution service.
Change data in records other than the final record is gathered outside of the updating transaction. The latency of collecting this information is based on the amount of time that it takes the change-capture agent to send the change to the correlation service plus the time required to package the change and forward the change to the distribution service. Related change data itself might have been updated or deleted between the transaction and the time that the information was forwarded to the distribution service. For this reason, map only identifying fields (for example, primary or foreign keys) in related records that are not subject to change.
If a related record is deleted between the time that an update transaction takes place and the time that the change is forwarded to the distribution service, related fields are passed to the distribution service as SQL NULL to indicate that the information is not available.
You might need to modify the application schema to ensure that related data information can be gathered in the case of record deletes. In some cases, CA-IDMS does not keep an owner pointer in the record prefix, and therefore owner information is not available if the record is deleted. Change capture is not supported in these cases.
If you require owner information for delete purposes, then you must change one or more set definitions in the path to include the LINKED TO OWNER statement so that owner pointers are maintained in the record prefix information. For more information about updating the schema, see your CA/CA-IDMS reference manuals.
In some cases, you might need to gather information from multiple record owners using different paths in the schema. Because change capture is supported for only a single path in the schema, gathering identifying fields from multiple paths is not possible in a single table mapping. However, because change messages sent to the distribution service are based on a single unit-of-work in the database, you can define multiple tables for change capture.
Using the CA-IDMS employee demo schema as an example, assume that you are interested in capturing changes to the employee record but you require both the office code and department ID that are associated with an employee when the employee is changed. You can map the path DEPARTMENT->EMPLOYEE as one table and OFFICE->EMPLOYEE as a second table to gather both the department ID and office ID when an employee is changed. The application that receives change data can combine the information from both mapped tables as a change to the employee record, and automatically trigger a change message for both table mappings.