Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
UltraLite maintains row state information. Tracking the state of tables and rows is particularly important for data synchronization.
An internal marker is used to keep track of the row state in an UltraLite database. Row states control transaction processing, recovery, and synchronization. When an application inserts, updates, or deletes a row, UltraLite modifies the state of the row to reflect the operation and the connection that performed the operation. When a transaction is committed, the states of all rows affected by the transaction are modified to reflect the commit. If an unexpected failure occurs during a commit, the entire transaction is rolled back. The following list summarizes these behaviors:
The state of each affected row is changed to reflect the fact that it was deleted. When a delete is undone through a rollback, the original state of the row is restored.
The affected rows are not always removed from memory. If the row has never been synchronized, then it is removed. If the row has been synchronized, then it is not removed, because the delete operation needs to be synchronized to the consolidated database first. After the next synchronization, the row is removed from memory.
A new version of the row is created. The states of the old and new rows are set so the old row is no longer visible and the new row is visible.
When a transaction is committed, the states of all rows affected by the transaction are modified to reflect the commit. When an update is synchronized, both the old and new versions of the row are needed to allow conflict detection and resolution. The old row is then deleted from the database and the new row simply becomes a normal row.
The row is added to the database and is marked as not committed.
The row is marked as committed and is also flagged as requiring synchronization with the consolidated database.