Next, create a trigger to store a pre-image for each row when it is updated. As with the insert trigger, this trigger is not
fired on download.

CREATE TRIGGER emp_upd AFTER UPDATE OF name,salary ON employee
REFERENCING OLD AS oldrow
FOR EACH ROW
BEGIN
INSERT INTO employee_preimages ON EXISTING SKIP VALUES(
oldrow.id, oldrow.name, oldrow.salary, CURRENT TIMESTAMP );
END;

This trigger stores a pre-image row each time a row is updated (unless two updates come so close together that they get the
same timestamp). At first glance this looks wasteful. It would be tempting to only store a pre-image for the row if there
is not already one in the table, and then count on the sp_hook_dbmlsync_upload_end hook to delete pre-images once they have
been uploaded.

However, the sp_hook_dbmlsync_upload_end hook is not reliable for this purpose. The hook may not be called if a hardware or
software failure stops dbmlsync after the upload is sent but before it is acknowledged, resulting in rows not being deleted
from the pre-images table even though they have been successfully uploaded. Also, when a communication failure occurs dbmlsync
may not receive an acknowledgement from the server for an upload. In this case, the upload status passed to the hook is 'unknown'.
When this happens there is no way for the hook to tell if the pre-images table should be cleaned or left intact. By storing
multiple pre-images, the correct one can always be selected based on the start progress when the upload is built.

This stored procedure returns one result set that has twice as many columns as the other scripts: it contains the pre-image
(the values in the row the last time it was received from, or successfully uploaded to, the MobiLink server), and the post-image
(the values to be entered into the consolidated database).

The pre-image is the earliest set of values in employee_preimages that was recorded after the start_progress. This example
does not correctly handle existing rows that are deleted and then reinserted. In a more complete solution, these would be
uploaded as an update.

Résultat

A table is created to store pre-images, a trigger is created to store pre-images of each row that is updated, and a stored
procedure is created to handle the updates.