I've implemented a standard timestamp-based download in a MobiLink setting with SQL Anywhere 16 as consolidated and remote.
- The table has a timestamp column called last_modified_ts
- There is a shadow table with the primary key columns, and a deleted timestamp column (also called last_modified_ts)
- There is a delete trigger that inserts into the shadow table
- There is an insert trigger that deletes from the shadow table
- The download_delete_cursor looks like this:
SELECT t.PkCol1, t.PkCol2
FROM ShadowTable t
WHERE t.Last_Modified_Ts >= {ml s.last_table_download}
What I've observed is that when the remote deletes a row, this sequence occurs:
- Upload delete removes the row on consolidated
- Delete trigger fires, inserting a shadow table row using current timestamp
- Since current timestamp is > last_table_download, download_delete_cursor returns the row
- Remote attempts to delete the row, finds it isn't there
This happens with all uploaded actions. It's true this does no harm (delete has no row to delete, insert and update are both processed as updates, but with identical data to the row on the remote). But it is wasteful of bandwidth and synchronization time, especially when the remote makes a lot of changes.
Is there any method that prevents these redundant actions?
-Eric Murchie-Beyma