Cannot run custom ReplicationConflictFunction

[carlnewton]

I'm working with Access 2003, split database. I'm trying to apply a custom ReplicationConflictFunction as described in the VB Help file (and I've poured through many web pages looking for answers).

I believe that I've done everything as specified. However, when I synchronize a replica via the VB synchronize method and I have record conflicts, my custom function won't run. The default Conflict Resolver runs instead. I've read that the the optional DDL argument must be set to true or the custom function won't run and I think that I've done this properly using code that I've found on another site. I've stepped through it and appears to function as expected.

I'm trying to make this work from the front-end of a split database. I'm wondering if the ReplicationConflictFunction doesn't work when executed on a front-end? For example, on my front end if I look at the Replication menu the only menu option available is the 'Create Replica' option. I already have a master and local replica and I use code to set the connect strings to point to the desired back-end.

Has anybody seen this problem?

Thanks

 

[carlnewton]

Figured it out. This is one of those times that you come into work the next day and see the solution within minutes.

The master back and had to have the ReplicaConflictFunction set to a custom function. The conflict resolver must be run from the back end and not the front end. I thought that because I was initiating the Synchronize method from the front end that the default Conflict Resolver was running from the front end. Not correct. Makes sense.

I'm dissapointed to learn that the programmer can't disable the pop-up from Access which asks the user if he\she wants to resolve conflicts. I was hoping that the custom function would simply resolve the conflicts in a transparrent manner unless it determined that operator action is required.

 

[dfenton]

I think you exhibit a misapprehension about conflict resolution that I myself had until not so very long ago.

Forget for a moment about your custom conflict resolution function and consider what happens by default. When a conflict exists between two replicas, the conflict is RESOLVED by Jet in favor of one version of the record or the other using Jet's default conflict resolution rules (based on replica priority and other factors). At that point both replicas have the same data in them, i.e., the data from the winning conflict record.

When you're notified that conflicts exist and the conflict resolver opens, THE CONFLICT HAS ALREADY BEEN RESOLVED! All the conflict resolver does is allow you to evaluate whether the conflict was *correctly* resolved, and provides an interface for you to override the default resolution.

When you create a custom conflict resolution function, you have not done anything but changed what happens during the synch. Instead of Jet's default conflict resolution rules, your rules are used. But Jet still knows there were conflicts and records the winning and losing records in the relevant conflict tables. And when there are conflict tables, Access asks you if you want to resolve the conflicts.

In order to override the default behavior, you have to eliminate the need for Access to run the conflict resolver, and the way you do that is by deleting the conflict records from the conflict tables. When you've done that, you won't get the prompt.

Of course, you've also lost the data that allows you to confirm that the conflict was correctly resolved by your conflict resolution algorithm. Thus, if you want to have the user check the results, you have to create your own conflict resolver to present the records in the conflict table. Or, you can launch the default conflict resolver at the end of your conflict resolution code so that the conflict tables will be empty when the user re-opens the database after they have synched (assuming, of course, that they don't skip resolving any of the conflicts).