Merge Replication Problem

Hi all I have a problem !!!
I use a Merge replication between 2 SQL Servers (I try with PUSH or PULL
Subscription but same problem)
Each morning in the server A I have scheduled an Import from exterenal data
( I make a DELETE all table and INSERT al data each morning)
After I schedule the creation of Snapshot in the Publisher and each hour is
scheduled the Merge replication (PUSH or PULL is the same)
The result is that in the Subscriber it make correctly the DELETE but not
the INSERT, the table in the Subscriber is empty and for all the day it says
"No merge data to replicate"
If manually it make the reinitialization in the Subscription, next merge
replication work perfectly and it works for all the day until next morning
when the script make the Import (DELETE with INSERT)
Some suggestions? Please...
Thanks a lot
Bonato Pierantonio, MCSD
Bonato - how are you doing the insert? There are 2 common reasons why the
merge triggers don't fire:
(1) If you bulk insert the rows and choose the defaults, then FIRE_TRIGGERS
is false and consequently the rows are not added to MSmerge_contents.
(2) If you do a fast-load using the Transform Data task in DTS
Fixing either of these will help new imports. In the case of already-added
rows which need replicating, you need to run sp_addtabletocontents to
include the rows then resynchronise. Alternatively you can use
sp_mergedummyupdate for a single row. For the fast load case, in future if
you deselect the check box the triggers will fire.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Merge replication data loss

I have serious problem regarding merge replication. After couple of pull
subscription synchronizations, data loss occurred in several tables (both
publisher and subscriber databases).
Publication has 62 articles, but only few are affected. Agents reports several
errors (including really nasty "general network failure").
I think problem is not in dynamic or join filters, because some of those
tables are not filtered at all.
Example: with tables T1 and T2 (FK constraint) users confirmed data loss in
child table T2 "right after synchronization" (sometimes couple of hundreds of
records).
So, question is how this could possibly happen (FK constraint maybe or general
network failure)?
Any help is appreciated,
Tom
general network error means your network hic cupped.
Merge replication refreshes the data on the subscriber when you send the
snapshot. This could account for the data loss. Also check the conflict
viewer to see if there is a record of conflicts which also might account for
it.
Make sure if you have any cascading deletes that they are disabled on the
subscriber.
"Tom" <tomislav.hrvoic.rimuv.dis@.inet.hr> wrote in message
news:uM5NnqIGEHA.4084@.TK2MSFTNGP11.phx.gbl...
> I have serious problem regarding merge replication. After couple of pull
> subscription synchronizations, data loss occurred in several tables (both
> publisher and subscriber databases).
> Publication has 62 articles, but only few are affected. Agents reports
several
> errors (including really nasty "general network failure").
> I think problem is not in dynamic or join filters, because some of those
> tables are not filtered at all.
> Example: with tables T1 and T2 (FK constraint) users confirmed data loss
in
> child table T2 "right after synchronization" (sometimes couple of hundreds
of
> records).
> So, question is how this could possibly happen (FK constraint maybe or
general
> network failure)?
> Any help is appreciated,
> Tom
>
>
|||what type of connectivity you are using?
those records might be on the publisher, you just need to
update the child records and replicate them to subscriber.

>--Original Message--
>general network error means your network hic cupped.
>Merge replication refreshes the data on the subscriber
when you send the
>snapshot. This could account for the data loss. Also
check the conflict
>viewer to see if there is a record of conflicts which
also might account for
>it.
>Make sure if you have any cascading deletes that they are
disabled on the
>subscriber.
>"Tom" <tomislav.hrvoic.rimuv.dis@.inet.hr> wrote in message
>news:uM5NnqIGEHA.4084@.TK2MSFTNGP11.phx.gbl...
After couple of pull
several tables (both
Agents reports
>several
failure").
because some of those
confirmed data loss
>in
couple of hundreds
>of
constraint maybe or
>general
>
>.
>
|||"Kiran" <anonymous@.discussions.microsoft.com> wrote in message
news:175be01c418c4$e0f0f180$a301280a@.phx.gbl...
> what type of connectivity you are using?
Subscribers use 56K modem or ISDN adapter to dial-in to company domain.
Network protocol is TCP/IP, DNS works fine, I did notice some lost packets
when pinging publisher from subsribers. However, that was before system
administrators replaced dial-in server and reconfigured network (replication
data loss problem is still unsolved though).

> those records might be on the publisher, you just need to
> update the child records and replicate them to subscriber.
Nope, older database backup is the only place where I can find those
records. Publisher is also missing those records and that makes it very
tricky.
Regards,
Tom