Key Points: Primary Key Behavior

• Primary Key Behavior has to with how TimeXtender should treat primary key violations.
• There are three options for the primary key violations, Error, Warning, and None.
• Primary Key Behavior can be configured at the project or table

Key Steps: Primary Key Behavior

Configure project level Primary Key Behavior

1. Open Advanced Settings under Edit Project
2. Select the Primary Key Behavior desired for your project defaults

Configure table level Primary Key Behavior

1. Open General tab under Table Settings
2. Select the Primary Key Behavior desired, which can override the project defaults

Understanding Primary Key Behavior

Primary key behavior has to with how TimeXtender should treat primary key violations. By default, primary key behavior is set at the project level, though each table's primary key violation behavior can be configured.

There are three types of Primary Key Behavior.

• Error: TimeXtender moves the invalid record to the error table. This means data will be missing from the valid instance of the table.
• Warning: TimeXtender copies the invalid record to the warnings table and the valid instance of the table. You will not be missing data from the valid table. However, you might need to handle the violated rule in some way.
• None to ignore the violation

Incremental loading relies on primary keys to compare the incoming records in the raw table with the existing records in the valid table. An incoming record that does not exist in the valid table based on the primary key comparison will be inserted as a new record. Existing records in the valid table will be updated with the values of the incoming record in the raw table.

The prerequisites for using source based incremental load are:

• A Unique primary key must be defined on the table. The Primary Key is used to identify whether an incoming record is new or an update of an existing record
• One or more fields in the source table can identify new or modified records