Reg,
Turns out we have a handle_error procedure that ignores PK not unique among other things, then keeps going (returns 1000). Long story, but we'd be at a standstill if we didn't do this. Then we have someone review the error logs to fix whatever it was. Okay, so that explains the lost data. Maybe it's time to review our handle_error procedure.
However, I think I see a double-bind in the logic when prevent_article_pk_update is combined with a user who wants to change the case of a PK value. At the remote, it of course has to be done as a delete/insert. A perfectly legal action. Ordinarily, that would upload as an update, but it CAN'T when prevent_article_pk_update is on, because the consolidated won't be allowed to do an update. So the other choice is to upload the delete and the insert. But MobiLink processes them in the wrong order.
And I DID get an update when the inserted row had the same case as the deleted row. It's only when I changed the case that the upload became a separate delete and insert. But again, whichever way the upload is done, it can't work.
It would be nice if prevent_article_pk_update were able to recognize that a case change doesn't change the identity of the row in a case-insensitive database, and allow the update.
Short of that, can you see any way to get MobiLink to handle my user's delete/insert?
Thanks,
-Eric