...
The consequence is that the SQL issued at the apply APPLY database is not the same issued against mine MINE – instead, each SQL updates/deletes/inserts exactly one row, applying just one change.
...
- SQL affects zero rows. This causes data divergence and so a conflict is raised. This could also mean that the target data has changed independently of the source data.
- SQL affects more than one row. This causes data divergence and so a conflict is raised.
- Oracle error. This can range from usual primary key or foreign key violation (another type of data divergence) to purely technical reasons (cannot extend datafile).
- Lock timeout. If the apply APPLY waits for a row lock more than WATCHDOG_TIMEOUT seconds, a conflict is also reported.
...
- Data divergence means that the data between the source and the target database is no longer in sync. The sooner data divergence is detected the easier it is too fix. Dbvisit Replicate will detect and notify as soon as any of the above issues are true (unless default conflict settings have been changed).
- When applying a row-change, previous values of the row at apply APPLY are checked (by means of adding them to the where clause). This effectively detects if the data in that row are inconsistent between mine MINE and applyAPPLY, and this is reported as a conflict, "0 rows updated/deleted." This can happen for update or delete only (there is no previous row to check for insert) and due to its special role, it can be handled differently.
...