Row not found at Subscriber

When we inserted a row at the Publisher -- this is error we got:
The row was not found at the Subscriber when applying the replicated command.
Since this was a new row, why would I get this error.
Unrelated question: we do not proprogate changes from the Subscriber to the
Publisher. However, there is one field that is allowed to be updated at the
subscriber. All other data is read-only.
What effect will this have on replication. That same field is replicated.
Logic tells me the updated subsriber field will be overwritten by the next
replication.
WR
When you updated the row at the subscriber, did you change its primary key?
If you did, this is probably why you are getting this error. Replication
uses the PK to determine which row on the subscriber to modify. You can
enable logging as per this kb article to determine which row replication is
failing on.
http://support.microsoft.com/default...b;en-us;312292
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"WhiskyRomeo" <WhiskyRomeo@.discussions.microsoft.com> wrote in message
news:1BBA4901-21F7-4023-AFAA-811F3F78BB31@.microsoft.com...
> When we inserted a row at the Publisher -- this is error we got:
> The row was not found at the Subscriber when applying the replicated
command.
> Since this was a new row, why would I get this error.
> Unrelated question: we do not proprogate changes from the Subscriber to
the
> Publisher. However, there is one field that is allowed to be updated at
the
> subscriber. All other data is read-only.
> What effect will this have on replication. That same field is replicated.
> Logic tells me the updated subsriber field will be overwritten by the next
> replication.
> --
> WR
|||I will enable logging; but the primary key cannot be updated (it is an
identity field at the publisher database).
Adminstrators of a local Windows .Net application can setup users who are
authorized to view data on the web in their Windows application. Data that
is viewed on the web is Pushed to a database running on a Server on the
internet. When a web user is initially set up in the local windows
application, the password for that user is initially set.
When the web user logs in for the first time he must change his password.
That is the only write activity allowed on the web (the subscriber). My
first question related to the fact, if that User was later updated at that
local application, wouldn't that overwrite any password update at the
subscriber site. If this is the case, can I allow updating the publisher for
only that column or record?
Concerning the other errror: I do recall deleting the same contact via EM
at both the Windows site and the Web site. Could this have caused this
problem? If so, how can I repair it?
wrl
"Hilary Cotter" wrote:

> When you updated the row at the subscriber, did you change its primary key?
> If you did, this is probably why you are getting this error. Replication
> uses the PK to determine which row on the subscriber to modify. You can
> enable logging as per this kb article to determine which row replication is
> failing on.
> http://support.microsoft.com/default...b;en-us;312292
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "WhiskyRomeo" <WhiskyRomeo@.discussions.microsoft.com> wrote in message
> news:1BBA4901-21F7-4023-AFAA-811F3F78BB31@.microsoft.com...
> command.
> the
> the
>
>

Row not found at Subscriber

This is a srange error because I found the row its looking
for at the subscriber..
The row was not found at the Subscriber when applying the
replicated command.
Any ideas? This one is a big one.
niv
Niv,
please can you post up the full error message, and explain what type of
replication you are using.
If it is transactional, the row being looked for will be based on OK, while
if merge it'll be based on guid.
If it is transactional, use sp_browsereplcmds to get the command and try to
run it yourself in QA if it is an update and let's see what tat returns.
HTH,
Paul Ibison
|||Enable replication logging as outlined in the kb article. It will tell you exactly which row it is failing on.
http://support.microsoft.com/default...&Product=sql2k
Then you can either select the agent profile to continue on data consistency errors or you can manually fill in the data by hand.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Paul Ibison" wrote:

> Niv,
> please can you post up the full error message, and explain what type of
> replication you are using.
> If it is transactional, the row being looked for will be based on OK, while
> if merge it'll be based on guid.
> If it is transactional, use sp_browsereplcmds to get the command and try to
> run it yourself in QA if it is an update and let's see what tat returns.
> HTH,
> Paul Ibison
>
>
|||Sorry for typo - should be PK not OK.
Further trhinking - I suspect that you don't have updatable subscribers and
someone has removed the row. If this is the case then you can readd the row
or skip the error, as Hilary points out.
Regards,
Paul Ibison
|||The strange this is, I searched for the row that could not
be found by the replication agent and found it.
This is why I dont understand why the agent seems to think
the row does not exist.
niv
>--Original Message--
>Enable replication logging as outlined in the kb article.
It will tell you exactly which row it is failing on.
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;312292&Product=sql2k
>Then you can either select the agent profile to continue
on data consistency errors or you can manually fill in the
data by hand.[vbcol=seagreen]
>--
>Looking for a SQL Server replication book?
>http://www.nwsu.com/0974973602.html
>
>
>"Paul Ibison" wrote:
explain what type of[vbcol=seagreen]
be based on OK, while[vbcol=seagreen]
the command and try to[vbcol=seagreen]
what tat returns.
>.
>
|||Niv,
can you try my original suggestion - get hold of the error
causing command and run it yourself in QA. This statement
should call an update stored procedure and the SP will
refer to the row by PK value. Investigating this way
should point out what the issue is.
Regards,
Paul Ibison
sql