Managing Failed RS Execution History Records
When a Replication Solution replicates data from one datastore to another, the rules of the receiving datastore can impact whether or not the replication is successful. In some cases you may need to modify the source database or the source data itself to successfully replicate the database. To locate failed records in an Replication Solution execution, go to Execution History Details. See Viewing Execution History Details.
Dynamics CRM Replications sometimes fail because data entered in Dynamics CRM exceeds the field length specified for a field in the Dynamics CRM schema. That schema is used to set the parameters of the source datastore in the target datastore, such as field length, data type, and which fields are associated with a specific entity. When there is a mismatch between the source schema and the source data being sent to the target, the replication fails. Review the example below for a specific use case scenario involving a Dynamics CRM replication failure and resolution options.
Example
Assume that your Replication Solution is replicating data from Dynamics CRM into a SQL database. The data in one of the Dynamics CRM fields exceeds the field length designated in the schema. SQL is very strict and rejects the incoming record causing the replication process to stop and generating a fatal error in the Execution History for the Solution. Subsequent records within that entity being processed are not replicated because any skipped records cannot be retrieved the next time the Replication Solution runs. The RS Solution continues with the next entity.
Anytime the RS Solution runs after the initial replication, the Solution only replicates new and updated records. To be retrieved for replication, new and updated records in the Source must have a datetime stamp that is newer than the record with the most recent datetime stamp stored in the target entity. When a record fails, the Replication Solution cannot simply skip the failed record and continue with the next record, because the invalid record's datetime stamp will be older than the most recent datetime stamp in the target and it will not be retrieved the next time the Solution runs.
If you were running the Replication Solution using the database tables shown below, the record for Bob Smith would not be retrieved to be replicated. Bob Smith's date modified, 11/12/2014, is older than the most recent date in the target table, 12/09/2014. Records for John Jones and Sue Brown would be retrieved because their modified dates are newer than 12/09/2014.
Source Contact Database Table
| Contact Name | Date Modified |
|---|---|
|
Bob Smith |
11/12/2014 |
|
John Jones |
12/14/2014 |
|
Sue Brown |
12/15/2014 |
Target Contact Database Table
| Contact Name | Date Modified |
|---|---|
|
Bill Hughes |
12/09/2014 |
|
Jane Green |
12/06/2014 |
Resolution Options
Use the information shown in the Execution History for the Solution to determine which record failed and do one of the following:
- Correct the source data and reprocess the failed records.
- Modify the source field parameters, such as length or data type, to match the data causing the error. For example, if the field length in the source is set to 10 characters and the data for that field in the problem record is 20 characters, set the field length to 20 characters. Run the Replication Solution again. When the Replication Solution is re-run, TIBCO Scribe® Online validates the source schema against the target schema and updates the target with any schema changes found in the source. See Editing The Source Schema.
- Modify the field parameters in the target to match the source data causing the error.
Note: After resetting metadata, check the target schema to make sure the field parameters are still correct. If you reset metadata, field parameters in the target may be reset to match the schema in the source, depending on the parameter that was changed.
Note: Contact your database administrator before modifying field parameters in source or target datastores.
Note: If you use a SQL script to create target database tables in a production environment, verify that the indexes and data for the primary keys are correct in that database before running an Replication Solution. An incorrect index or missing primary key data can cause duplicate records during a replication.
- Refer to the Replication Services Error: "Failed to insert record: String or binary data would be truncated." Knowledge Base Article for additional details.
Related Topics
Managing TIBCO Scribe® Online RS Solutions
Viewing Execution History Details
