Replication issue- data changes not seen at subscriber

Hi,
I have very simple one way transactional replication. There are multiple
publications. Every publication has multiple articles. All data in tables
have been published without a filter condition. Recently i have been getting
compalints about data sync. Changes appliad at publisher are not being
propated to subscriber. I verified agents log reader and distributor are
running fine, no error msgs. I manually updated one table in a publication
where i ususally encounter problems, but the change have not been propagated
to subsciber. It is working fine for other table updates. All publications
are from same database. and they go to same destination db.
Can someone pass me, how to troubleshoot to find out where is the problem?.
I reinitialized it , but not no use, didn't work.
Thanks,
Subbu.
Hi,
A way to confirm in transactional replication that sql server is not
replicating a specific table of a publication (among other things) is to
verify that when a transaction is made at the publisher the corresponding
store procedure is executed at the subscriber, that is:
spMS_upd_yourtablename
spMS_ins_yourtablename
spMS_del_yourtablename
You can modify this stored procedures (after a backup, to be able to reverse
the procedure after troubleshooting) to include some code that will led you
to determine if the present stored procedure is being executed and if the
intended result is achieved.
If you come to the conclusion that sql is not replicating the table, it’s
advisable that you apply the latest service pack (all severs) and re create
de publications and subscriptions.
Regards,
Rafael Meza
"subbu" escribió:

> Hi,
> I have very simple one way transactional replication. There are multiple
> publications. Every publication has multiple articles. All data in tables
> have been published without a filter condition. Recently i have been getting
> compalints about data sync. Changes appliad at publisher are not being
> propated to subscriber. I verified agents log reader and distributor are
> running fine, no error msgs. I manually updated one table in a publication
> where i ususally encounter problems, but the change have not been propagated
> to subsciber. It is working fine for other table updates. All publications
> are from same database. and they go to same destination db.
> Can someone pass me, how to troubleshoot to find out where is the problem?.
> I reinitialized it , but not no use, didn't work.
> Thanks,
> Subbu.
>
>
|||Hi,
Thanks for the response.
As per my understanding, logreader will make entry into repl_commands table
in distributor db as soon as there is a change on published data. Then
distributor will pickup the cmds from this table to apply on subscribers.
From the moment i made some changes to the published table, i watched
repl_commands table in distributor to see the transaction, it never got into
the (repl_commands) table.
My question is why logreader agent is not picking up the changes i made.
Is there a way to troubleshoot or reset secondary log truncation mark
without droping and recreating replication.
Thanks,
Subbu.
whether they have been read by logreader agent. there are no entries
"rafameza" <rafameza@.discussions.microsoft.com> wrote in message
news:30218EEC-EB8E-4F22-AF9C-766DC1E4348D@.microsoft.com...
> Hi,
> A way to confirm in transactional replication that sql server is not
> replicating a specific table of a publication (among other things) is to
> verify that when a transaction is made at the publisher the corresponding
> store procedure is executed at the subscriber, that is:
> spMS_upd_yourtablename
> spMS_ins_yourtablename
> spMS_del_yourtablename
> You can modify this stored procedures (after a backup, to be able to
reverse
> the procedure after troubleshooting) to include some code that will led
you
> to determine if the present stored procedure is being executed and if the
> intended result is achieved.
> If you come to the conclusion that sql is not replicating the table, it's
> advisable that you apply the latest service pack (all severs) and re
create[vbcol=seagreen]
> de publications and subscriptions.
> Regards,
> Rafael Meza
> "subbu" escribi:
tables[vbcol=seagreen]
getting[vbcol=seagreen]
publication[vbcol=seagreen]
propagated[vbcol=seagreen]
publications[vbcol=seagreen]
problem?.[vbcol=seagreen]