Thanks for the suggestion Gianluca. Since we corresponded last I have discovered a great deal about SQL replication. None of it good for me.

Simply the replication topologies(Merge/Transactional/Peer-to-Peer) are not compatible with each other unless Automatic Identity range is set to manual and managed manually.

Additionally the same article in in two merge publications cannot be Bidirectional in one publication and Download-only(subscriber edits or not) in the other.

However your suggestion about preventing write back got me thinking.

Do you think I could set up two merge publications (essentially identical) with bi-directional (these wouldn't conflict with each other) and have a subscriber that is "denywrite" such that the subscriber can pull the publication but if changes are made at the subscriber, are "denied" from being written back on the next merge?

I've been experimenting and I haven't succeeded with this. I'm not sure what user or mechanism can be denied write\inert\update\delete.

I've tried setting denydatawriter on the PAL subscriber and the merge replication agent. Didn't work.

I haven't quite worked out what user is used to perform the write of merged data.

I'll need to dig through the various users and permission configured for publications.

Thanks for your suggestion.