I'll answer this in 2 parts.
First, if you want to get the data back in sync, then you should reinitialize. Check to see what is changing the data though. If this is a big table, reinitialization could take a while.
Secondly, If the subscriber isn't read only and you are trying to do transactional replication, you are going to run into this error a lot. People, apps, whatever can change a couple rows and boom, the emails start flying in. If you need both sides to be able to CRUD data, then I would use merge replication. This enables both sides to update data.
To get this to work I scheduled switching off the 'immediate sync' to very low traffic period
EXEC sp_changepublication
@publication = 'statics',
@property = 'Immediate_sync',
@value = 'false'
GO
I then ran a snapshot which only took a fraction of the time at 6 mins.
I then had to drop the current subscription for that article only
EXEC sp_dropsubscription
@publication = 'statics',
@article = 'dbo.SupplierCorporatePayAccountLink_tbl',
@subscriber = 'SURVIVOR'
and rerun the snapshot. Then i could add the subscription back into the publication
EXEC sp_addsubscription
@publication = 'statics',
@article = 'dbo.SupplierCorporatePayAccountLink_tbl',
@subscriber = 'SURVIVOR',
@destination_db = 'MLT-Replicated',
@reserved='Internal'
but it would not allow this without the fairly obscure setting
@reserved ='Internal'
or I got an error message saying I needed to subscribe to all articles.... replication then automatically sync'd the new table. I'm a happy man as this has been causing me some long nights!
Best Answer
The whole point of snapshot is to provide a point in time copy of the articles involved in replication. It does it when generating the snapshot files from the publisher by locking the tables until the snapshot is finished for that particular article.
You should plan to reinitialize during less activity time of your server.
In SQL Server 2005, Concurrent snapshot is by default (applies to only PUSH subscriptions)
sync_method=concurrentWhat it does is that it produces native-mode bulk copy program output of all tables but does not lock tables during the snapshot.
Also, as per your comment, if you are doing schema changes (e.g. adding new columns) and want to replicate those across to subscribers, you can use this method.