Why does Pervasync implement a sync engine instead of using a simple time stamp based database synchronization scheme like a lot of others?
A. We know that in synchronization you cannot simply record the SQL statements on one database and replay them on another database. The reason is that the client database typically only has a sub-set of server database data and the same SQL statement could do different things on server than on client. Instead, you should somehow track the changes to records/rows and apply the changes to the destination DB. The most popular change tracking method on server DB is based on timestamps. It looks very straightforward. You add a timestamp column to your table and update the timestamp column whenever you change a row. This can be done in your SQL statement or through triggers. By the way, deletes have to be tracked separately, maybe in a companion table. Then at sync time, the sync client would come in with a last sync timestamp and you select all the server changes that have a newer timestamp than the last sync timestamp. As I said, this is a widely used technique when people have to implemen
Related Questions
- When I try to use GROUP BY, I get the error "Database Engine Error: When GROUP BY exists, every simple field in projectors must be in GROUP BY." How do I fix it?
- How does the engine discern which data to retain? Is it based solely on the queries registered with the engine at the time the event comes in?
- Do I need to link Aestiva Procurement with a database engine?
