Resolving Replication Conflicts And Errors Very Weak In 5.0.0.6

Question

The current 5.0.0.6 release of 9ilite is very weak in the area of resolving replication conflicts. It seems like you need to create your own conflict handling routine. First, you need to read the C$EQ table in the mobile admin account to check if any errors have been logged. Then you need to read the CEQ$tablename table(s) from the application schema based upon the data contained in the C$EQ table. At this point you can change the data in the CEQ$tablename table and then call the consolidator api from your application to either remove or process the transaction that caused the conflict or error.
I've worked with Oracle Support on this and they don't even have any information on this. It is left up to the user to figure it out.
Perhaps this will be addressed in the 5.0.1 release.
I was wondering how some other developers where handling this issue.
Tom

Answer 1

You are correct, the method for bailing out of unresolved conflicts or errors is very lame. It would be 100x better if there were some sort of log file/log table entry giving a clue as to why the conflict is being dumped into the ceq$x table.
As far as workarounds, we're taking the approach of testing our app to the point that we hope no inserts into ceq$ ever happen. Probably a pipe dream, but hopefully later releases will address this.