Handling merge replication foreign key conflicts

I have SQL CE clients replicating against a SQL Server 2005 db using merge replication. The DB has a table A and a table B, which has a foreign key to table A. It is common in my application for records in table A to be deleted on the server. I'm running into issues when a table A record has been deleted, but table B records were created on the clients which point to that record. When I sync I get a conflict because the table B records cannot be applied at the server, and the table A delete cannot be applied at the client.

What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.

This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.

Thanks.
Any ideas on this?|||

presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows

- whether DRI or by trigger

if you were using transactional replication the delete child-then-parent would be part of same atomic transaction

- thus maybe you would get both or neither.

possibly using transactional repl with immediate updating would avoid updates to such ghosts.

however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation

seems that you could

1. write custom resolvers, or

2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]

3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]

HTH

Dick