I have a merge replication which I was unfortunate enough to start modifying, in a way that required the subscriptions to get re-initialized. It makes very good sense and all, since I was touching some filters. But in my case, I changed something and then changed it back, so I know that the result of the new snapshot and new initialization will be identical to what I had.
However, the snapshot is re-created and the subscription is marked for re-initialization. And now the snapshot fails to get re-applied because there are data in subscriber's tables and the .bcp files in the snapshot have some data to load (same, actually, as we know). I can empty the .bcp file and then it seems to move on to the next table, so that's my strategy for now. I just wonder if anybody sees any pitfalls here. I suspect they are many and deep, just that my lack of experience doesn't let me see them.
Best Answer
I've experimented quite extensively with the mentioned situation and it looks like there are different scenarios in which snapshot is re-created: sometimes they involve bulk data being transferred, sometimes they don't. I suppose that the logic on the Publication side is clever enough to see when re-initialization of a subscription will require data being loaded again, and when - not.
Sometimes it brings disaster though, like when you try to re-create a filter, aren't able to and then would have to drop the article and create it again with a filter. The data is actually good on both sides, even if it's not matching the filter on the subscription - well, so what - it will after some updates. The problem is that then the snapshot will be re-generated and subscription marked for re-init. But the table is full of (good) data already and more likely than not you get an error trying to apply the snapshot.
So then, as in my question, I took all the involved .bcp files and emptied them (with a powershell script as they were many). Deleting them didn't help, because snapshot realizes something's been stolen from it. But empty bulk data files are harmless and then everything goes through, thankfully!
I suppose you could find a scenario when your application would suffer from some data being temporary present that doesn't match the replication filter, but in my case I think everything is working - so far so good.