|
We use time stamp based synchronization and a table that is in both a consolidated and remote db. This table synchronizes updates from the consolidated to the remote. We don't want the remote updating this table so we have triggers that prevent this on the remote. Then, on the consolidated we have an upload_update event script that looks like this: update owner.table set last_modified_ts = now(*) where table-pk= {ml r.table-pk} So, if someone at the remote is determined to update that table the consolidated will not update but then will send the consolidated value back to the remote in the download_cursor based on the last_modified_ts being updated. This has been working. But in testing yesterday I saw this: I updated a value at the remote. The column I updated had a data type of varchar(7). Consolidated and remote match with this data type. I updated the last character in the column like this at the remote: original value: testing updated value: testina Then synchronized. The consolidated was not updated as expected. But the consolidated did not send its value back to the remote. I saw this in the mobilink server logfile: Does "Ignoring redundant row" mean it's not sending the consolidated value back to the remote? Which is what I'm assuming. I did some further testing and the redundant row only seems to come up when the character length of the value isn't updated but a character in the value is updated. If I update the value to "test" changing the length, then the consolidated sends the update to the remote. But if I update the value to "testina", still 7 characters, it will not send the update. What constitutes an "update" for the download_cursor to send an update to the remote? From what I understand, the upload is compared to the download and if they match then you get the redundant row information line. Is this correct? Appreciate the help. |
|
Thank you Breck and Volker. What we had is a table with a funky primary key ( a blank ' ') and a reserved word used as the value in the varchar(7) column ('unknown'). We decided to change the 'unknown' to 'UNK' and that did give the expected behavior. |
What version and build are you using?
If the posted text has been edited, please show us the original... even the slightest error in editing has been known to obscure the cause of problems.
It is also sad that this Google search
only yields 3 hits, and two of those appear to have been deleted by The Great SAP Doc Purge.
The third hit is an ancient Palm Ultralite how-to which shows the message but doesn't explain it:
If memory serves, the message is produced by the feature described in How the upload is processed: "It would be difficult to write a download_cursor script that omits from the download rows that were sent as part of the upload. For this reason, the MobiLink server automatically removes these rows from the download."
...apparently, "difficult to write" is an understatement, even for the engineers.
Perhaps your trigger and other logic somehow magically interferes with the method whereby "the MobiLink server automatically removes these rows"... perhaps some adjustment to the way your code works can bypass the problem and restore correct behavior.
...it won't be the first time code had to be changed to avoid a bug.
Another idea would be to handle that as some kind of update conflict, which it is basically, when the cons does not accept the remote's change. And conflicting rows are downloaded back to the remote they came from...