It seems that you don't use any of the "conflict detection" scripts. As such, the conflict seems to get unnoticed, and the complete contents of the last synchronized row becomes the new consolidated contents.

This means that MobiLink is by default working on a per row base overwriting either non or all values. So it's not possible to send updates of single columns without customer script handler. I will have to write a custom resolve script for all my tables in the synchronization (more than 100)?
(Inserting in a temptable on conflict resolution makes sense when it comes to overwrites on the same column)

AFAIK, yes - but I'm no ML expert, so you better wait for a clarification...

Aside: AFAIK, that is a difference to SQL Remote where the actual UPDATE statement is replicated whereas ML sents whole rows with "before and after" images):

With SQL Remote, if you just modify one column, only that one column is "sent" along with the PK - and the "verify_all_columns" option would tell if the other columns would be used for conflict detection, too.)

The upload_fetch_column_conflict event is the same as upload_fetch, except that with it the MobiLink server only detects a conflict for a row when the same column was updated on the remote database and the consolidated database since the last synchronization. Different users can update the same row without generating a conflict, as long as they don't update the same column. The upload_fetch_column_conflict event can only be applied to synchronization tables that have no BLOBs.

When using an upload_fetch_column_conflict script and no conflict is detected, the row values passed to your upload_update script come from either the remote database's upload or the current consolidated values from your upload_fetch_column_conflict script. The remote database's value is used for columns that were updated on the remote database, otherwise the current consolidated value is used. In other words, only the columns that were updated on the remote database are updated in the consolidated.

Reg's approach would be best to minimize conflicts, but conflicts may still occur, eg. if both users update the same row. The out-of-box behaviour of "last in wins" may be good enough for you, but it might not. Your application scripts will need to either ignore one of the updates, blend them, or log the conflict somewhere.

Attached a simple repro. I don't actually do any conflict resolution (you can if it's detected and you want to) in the scripts, but the sample shows that the existence of the upload_fetch_column_conflict event causes MobiLink to only insert columns that have changed from the remote into the upload_update event, and other parameters are from the values fetched from the consolidated.