Row Count Errors

Incremental replication operations depend on having unique fields to identify changes that have been committed to the source database. After the baseline replication completes, an incremental replication subscription may fail with row count errors if the change data cannot be reconciled between the source and target databases.

If the collation sequence of the database is Case Insensitive, character fields that are uniquely identified on the host may no longer be unique when they are replicated to the target. For example, fields named “First” and “first” that are unique on the source would not be unique if the target database is configured to be insensitive to capitalization. Certain data types that have different levels of precision in different database systems also can create non-unique fields. For example, Db2 for i supports microsecond timestamps whereas Microsoft SQL Server only supports millisecond precision.

To help ensure unique fields, configure the collation sequence of the target database, especially if it is a SQL Server database, to be Case Sensitive. You can use SQL Server Studio to verify the collation sequence by viewing the database properties.

A case-sensitive collation has the characters “CS” appended to the Collation Designator. For example, the collation SQL_Latin1_General_CP1_CS_AS is a case-sensitive collation for U.S. English systems. You can set the collation for a new database using  SQL Server Studio. To change the collation for an existing database, use the ALTER DATABASE (Transact-SQL) command with the COLLATE clause. Refer to your database system documentation for details on specifying the collation sequence for databases it manages.

If the host database is Db2 for i or Oracle, you also can use the Relative Record Number (RRN) or ROWID that SQDR Plus adds to the staging table instead of, or in addition to, using other primary keys or indexes to identify the change data.  Using the RRN can help overcome problems caused when a unique field on the source is no longer unique on the target due to differences in how the different database systems support data types such as timestamp, which has microsecond precision in Db2 for iSeries whereas SQL Server supports only millisecond precision.

The TargetChecker administrative tool can help determine whether you are experiencing row count errors.

If you receive row count errors StarQuest Technical Support may ask that you enable logging to gather more details about the failure.