How to find rows marked for replication?

SQL Server 2005
Someone here attempted to update about 3000 rows in a table that is in
replication (on the publisher side). We are using push replication.
The rows were updated successfully on the publisher table, but for some
reason, it serioulsy locked up the replicated table on the subscriber
side. Because of the locking problem, none of the rows actually got
updated on the subscriber side.
At this point, the DBA turned off replication to release the locks on
the table (which it did).
So, now the situation is, there's a bunch of rows marked for
replication that haven't yet been successfully replicated. My question
is, is there a way to "undo" the changes? If so, how would one do this.
The other option is to turn replication on later tonight when no users
are online, I suppose.
Has anyone else had this problem and how did you solve it?
Thanks
Are you using transactional replication? If so, then please try using
sp_browsereplcmds. If you are using merge, then you could try my routine
(http://www.replicationanswers.com/Script9.asp).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Yes, thank you
This information also corresponds to the number of rows in the
"msrepl_commands" table.
I was told that I can simply truncate the msrepl_commands table to
clear the slate, so to speak. Is this correct? And will it hurt
anything?
Paul Ibison wrote:
> Are you using transactional replication? If so, then please try using
> sp_browsereplcmds. If you are using merge, then you could try my routine
> (http://www.replicationanswers.com/Script9.asp).
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||This sort of thing is possible - after all it is essentially what the
cleanup agent does. However you'll also need to take into account
msrepl_transactions, and be sure to delete only relevant commands ie not
ones belonging to other articles or publications and finally you'll be
creating a situation of non-convergence which might lead to synchronization
errors later on. All this is taking you into unsupported territory so I'd
recommend simply synchronizing during a quiet time.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .