Merge replication over VPN

I currently have a client who needs to replicate a database between a server
in the office and a computer at home using a VPN connection.
Here is the currnet setup:
-Merge Replication
-Both the server and the client have SQLSERVERAgent logged in with the same
username and password for pass-through authentication
-Subscriber impersonates SqlServerAgent
-Anonymous subscription
The snapshot has been created successfully on the server and I am able to
register the client on the server's Enterprise Manager (so they can see each
other). The replication starts and runs for quite a while (most of the work
is done). Eventually, it fails with the message
//<servername>/<sharename>/<filname>.dri could not be propagated to the
subscriber. With no further details. I don't think it is security related,
because most of the work is already done.
Any ideas what I'm missing?
You might try, from the client, to see if you can browse this share. When I
have set it up, it required an entry in the HOSTS file to map the IP address
to the NETBIOS name.
HTH,
Paul Ibison
|||The share is visible. I fixed that with an entry in the HOSTS file in the
beginning.
"Paul Ibison" wrote:

> You might try, from the client, to see if you can browse this share. When I
> have set it up, it required an entry in the HOSTS file to map the IP address
> to the NETBIOS name.
> HTH,
> Paul Ibison
>
|||OK, if it is running, transferring the snapshot and fails after a while, you
might try increating the -QueryTimeout parameter of the merge agent's
profile.
HTH,
Paul Ibison
|||I did that already as well after having a timeout problem. The current
problem just says that the file could not be propagated to the subscriber.
"Paul Ibison" wrote:

> OK, if it is running, transferring the snapshot and fails after a while, you
> might try increating the -QueryTimeout parameter of the merge agent's
> profile.
> HTH,
> Paul Ibison
>
>
|||Problem Solved:
It turns out that there is no guarantee that the order that records are
inserted during replication will be the same as when they were inserted
originally. Therefore, it is possible that a chile record can be inserted
before its parent, causing a conflict with the foreign key constraint.
After setting all foreign key constraints to "not for replication", the
client took the snapshot without a problem.
"b1@.ckh013" wrote:

> I currently have a client who needs to replicate a database between a server
> in the office and a computer at home using a VPN connection.
> Here is the currnet setup:
> -Merge Replication
> -Both the server and the client have SQLSERVERAgent logged in with the same
> username and password for pass-through authentication
> -Subscriber impersonates SqlServerAgent
> -Anonymous subscription
> The snapshot has been created successfully on the server and I am able to
> register the client on the server's Enterprise Manager (so they can see each
> other). The replication starts and runs for quite a while (most of the work
> is done). Eventually, it fails with the message
> //<servername>/<sharename>/<filname>.dri could not be propagated to the
> subscriber. With no further details. I don't think it is security related,
> because most of the work is already done.
> Any ideas what I'm missing?