Sync: UPDATE on records that do not exist

Question

I have to similar cases that occur now and then:
1. user syncs from PDA, record ends up in EQ with "Update/delete error :: no data found". (EQ DML: UPDATE)
2. user syncs from PDA, record ends up in EQ with "integrity constraint (MIPSS.FK_EVENT__INSPECTION) violated - parent key not found" (EQ DML: INSERT)
Data ending up in EQ is deleted from the PDA according to the user.
Data is not accessible for deletion by anyone on the server side or on the PDA. I know that the last time this happened, the PDA user INSERTED (created) a new record (INSPECTION) and then UPDATED (edited) it before he did the sync. Is it possible that olite/Mobile server skips an INSERT when syncing or could there be something wrong with my publication?
Marius
Edited by: Marius H on Mar 24, 2009 4:08 AM

Answer 1

The uniqueness of the seqno$$ values is within clientid and tranid$$, so it is possible for the same seqno$$ values to be in a ceq$ table for different users and/or transactions.
In your example (assuming they are for the same clientid), tranid$$ 258 is the first upload (the tranid$$ increased for each sync for the same user), and therefore will need to be processed first. The seqno$$ value for the record for tranid$$ 258 looks like an update, rather than an insert from the range value (higher than the type I for tranid$$ 263) did you change the U to I when trying to fix the problem?
the version$$ values in the cfm$/ceq$ tables do not always have real values
if the record was uploaded as dmltype$$=I, the version$$ will normally be 1 (ie: first version of the record), but when the apply is done then if the PK does not exist, the record will be created and the cvr$ table inserted with version 1. If the PK does exist, then the record will be updated and the version value in the clg$ table added to.
if a record was downloaded to the client it would have a version number from the server, and update to this would normally include this version number so that the apply can check that the update is for that version of the record when checking for conflicts where the data has changed on both the server and the client.
If a record was created on the client and then updated, the version would probably be null as it is likely that this update would be changed to an insert when it is applied
the -1 is possibly a second update to the same record
When the apply process is done, the dmltype$$ from the upload is only used as a guide. for both I and U it tests if the PK exists and if so does an update, if not does an insert. for type D it checks the PK and if it exists, deletes the record, if it does not, then it ignores the record.
The processing order is clientid, tranid$$, seqno$$