"Could not continue scan with NOLOCK due to data" error during Replication Synchronization

I am receiving this message "Agent message code 601. Could not
continue scan with NOLOCK due to data" during the initial
synchronization after setting up a subscriber.
It is a straightforward tarnsactional replication of maybe twenty
tables.
I have never seen that message in the context of replication.
I think the 601 error looks to be slightly misleading as the previous
message in the log looks to indcate a successful snapshot
synchronization:
Delivered snapshot from the 'unc\serverX\20070208105750\' sub-folder
in 519625 milliseconds.
I have tried setting up the subscriber and publisher mulitple times
from scratch but always run into this message. Also all of the
replicated tables have multiple indexes and this is on a SQL Server
2005 SP1 Mirrored database. I have ran checkdb on database with no
problems found. This is halting the database from being replicated -
anyone know a way around this?On Feb 8, 5:14 pm, "Calculated" <sarahjco...@.gmail.com> wrote:
> I am receiving this message "Agent message code 601.Could notcontinue scan with NOLOCK due to data"duringthe initialsynchronizationafter setting up a subscriber.
> It is a straightforward tarnsactionalreplicationof maybe twenty
> tables.
> I have never seen that message in the context ofreplication.
> I think the 601errorlooks to be slightly misleading as the previous
> message in the log looks to indcate a successful snapshotsynchronization:
> Delivered snapshot from the 'unc\serverX\20070208105750\' sub-folder
> in 519625 milliseconds.
> I have tried setting up the subscriber and publisher mulitple times
> from scratch but always run into this message. Also all of the
> replicated tables have multiple indexes and this is on a SQL Server
> 2005 SP1 Mirrored database. I have ran checkdb on database with no
> problems found. This is halting the database from being replicated -
> anyone know a way around this?
Resolved this - if anyone else has this problem try adding a table at
a time to the publication article and re-initializing the subscription
until you identify the problem table. Then either filter the table to
break down into smaller chunks (largest table in db was causing
problem in my case) or play around with the copy clustered index and
copy nonclustered index options on the specific table.