Merge Replication Problem

We have a merge replication database with a publisher server and a distribution server. We made and publication with dynamic filters. We are using a pull suscriptor wich was installed with a backup from the publisher database.
First time we made it works we had no errors and no conflicts. However, later we had troubles with the suscriptor, it was trying to delete rows from some tables that we didn't modified, and it produced some conflicts because referential integrity on the
publisher database stopped it.
We didn't apply a initial snapshot because it had the same data of the publisher and we are using @.pre_creation_cmd = truncate but the suscription doesn't ignore it (suscription has the schema and data).
Deletes on this tables are imposible however the suscriptor always try to do them
What can I do to prevent this problem?
Is it necessary to apply always the initial snapshot and how can I do it if there is referential integrity among the tables into the publication?
Thanks.
you should put the NFR option on all constraints and relationships on the
publisher and subscriber.
This should solve most of the problems related to DRI relationships.
What is happening is that DRI is enforced on the Publisher as two (or more
statements). These changes are then replicated to the Subscriber. The
initiating transaction is executed on the Subscriber where the DRI
relationship is applied. Then the next statement where DRI was enforced on
the publisher makes its way to the subscriber where it is attempted to be
applied again. This is typically where your conflict occurs.
"Heiner Morales" <anonymous@.discussions.microsoft.com> wrote in message
news:5CDDA4F6-C4AD-4A33-A426-0AA554A54DD7@.microsoft.com...
> We have a merge replication database with a publisher server and a
distribution server. We made and publication with dynamic filters. We are
using a pull suscriptor wich was installed with a backup from the publisher
database.
> First time we made it works we had no errors and no conflicts. However,
later we had troubles with the suscriptor, it was trying to delete rows from
some tables that we didn't modified, and it produced some conflicts because
referential integrity on the publisher database stopped it.
> We didn't apply a initial snapshot because it had the same data of the
publisher and we are using @.pre_creation_cmd = truncate but the suscription
doesn't ignore it (suscription has the schema and data).
> Deletes on this tables are imposible however the suscriptor always try to
do them
> What can I do to prevent this problem?
> Is it necessary to apply always the initial snapshot and how can I do it
if there is referential integrity among the tables into the publication?
> Thanks.
>
sql