To start, it should be noted that you do not have to delete the remote rows from the device if you do not wish. UltraLite will use row-state markers to track which specific rows have changed in between synchronizations and will only attempt to upload those specific rows during the next synchronization session.

If you do wish to delete the rows as part of the synchronization download transaction, the mechanism to do this is the 'download_delete_cursor' table event on the MobiLink server. The idea behind this script is that you SELECT a set of primary keys to be sent back down to the remote for records that you wish to delete - the remote will then run those deletions as part of the download events on the remote. Part of developing this deletion mechanism is to figure out how to flag deletions from the consolidated database - this is typically done either through row-state markers on the table ("logical deletes") or by maintaining a separate table of keys to select from ("shadow delete"). Developing such a mechanism is discussed in greater detail in the documentation.

There are also options on how to specify how to handle deletes from the MobiLink Synchronization Model view.

Otherwise, you always have the regular UltraLite APIs that could be used from your client application to synchronize the UltraLite database, connect to the database afterwards, and perform your deletions manually.