We are experiencing inconsistent delete replication behavior when syncing a very small and stable ServiceNow table (≈10 rows) into SQL Server using CData Sync v26.
Despite following all recommended configurations and upgrading both Sync and the ServiceNow driver, record deletions in ServiceNow are occasionally not detected by CData Sync, resulting in extra rows remaining in the SQL destination.
This has caused incorrect data to appear in executive-level dashboards, impacting trust in reporting.
Observed Behavior
- Records are deleted in ServiceNow
- No incremental sync runs successfully with no errors
- The deleted records remain in SQL Server
- Dashboard shows more rows than exist in ServiceNow
- Manual SQL cleanup is required to restore accuracy
Example:
- Source (ServiceNow): 8 rows
- Target (SQL): 10 rows
- The extra 2 records no longer exist in ServiceNow
Expected Behavior
- Deleted records in ServiceNow should be reliably removed in SQL
- Sync behavior should be consistent regardless of table size
What We Have Already Done
✔ Upgraded to the latest CData Sync v26 build
✔ Upgraded to the latest ServiceNow connector version
✔ Verified schema stability (no column or structure changes)
✔ Tested multiple GetColumnsMetadata settings (OnUse)
✔ Reviewed replication logs (no delete-related errors reported)
✔ We are not using incremental replication because it is a small table
✔ Confirmed issue occurs even on a small table (~10 rows)
Questions for the Community / CData Team
- Are there known limitations with delete detection in the ServiceNow connector?
- Does CData Sync rely on:
sys_updated_on- soft-delete behavior
- tombstone records
- or another ServiceNow mechanism for deletes?
- Are there additional settings required to reliably detect deletions?
- Is this a known issue that requires an engineering fix?
- What is the recommended and supported way to guarantee delete consistency?


