This error occurred after about one hour of applying snapshot to subscribers database and caused restart of the whole process.

Investigation of error details in distribution database tables was lost time. First after monitoring of the full traffic against the subscriber database we have discovered that our error was caused by this statement:

EXEC(N'
CREATE UNIQUE NONCLUSTERED INDEX [UX_RecordCategory_Record_ID_Category_ID] ON [ts].[RecordCategory]([Record_ID],[Category_ID]) 
WITH (DATA_COMPRESSION = PAGE ) 
WHERE ([Record_ID] IS NOT NULL AND [Category_ID] IS NOT NULL)')

What’s wrong there? It’s maybe not visible at the first look but yes, there is serious syntax error: WITH (DATA_COMPRESSION = PAGE ) should be after the WHERE first:

EXEC(
N'CREATE UNIQUE NONCLUSTERED INDEX [UX_RecordCategory_Record_ID_Category_ID] ON [ts].[RecordCategory]([Record_ID],[Category_ID]) 
WHERE ([Record_ID] IS NOT NULL AND [Category_ID] IS NOT NULL) 
WITH (DATA_COMPRESSION = PAGE ) 
')

This invalid statement was hidden in one of *.idx files in snapshot folder. *.idx files are executed as last during snapshot application so this is the reason why we were waiting for this error more than one hour (and 60 GB of data inserted to subscriber DB).

The general message for the whole audience is that you simply cannot generate valid snapshot in case that your database contains filtered indexes with data compression at the same time. MS guys should do better job when testing new features:)

You can check your database for this kind of indexes with this query:

SELECT *
FROM sys.[indexes] [i]
INNER JOIN sys.[partitions] [p] ON [p].[object_id] = [i].[object_id] AND [p].[index_id] = [i].[index_id]
WHERE [i].[has_filter] = 1 AND [p].[data_compression_desc] <> 'NONE'

I have created Microsoft Collaborate item for this.

Below is simple script to generate required triggers for every table in database. You only need to set @ReplAccount variable to your replication system account. If you will later remove all triggers you can switch @DeleteOnly variable from 0 to 1.

DECLARE @Stmt NVARCHAR(MAX)
DECLARE @DeleteOnly BIT
DECLARE @ReplAccount NVARCHAR(128)

SET @ReplAccount = 'domain\account'
SET @DeleteOnly = 0

SET @Stmt = ''

SELECT 
	@Stmt = @Stmt + 
	CASE @DeleteOnly 
		WHEN 0 THEN 
			N'EXECUTE(''CREATE TRIGGER ['+ [sch].[name] + '].[trg_prevent_modify_' + [tab].[name] + '] 
							ON [' + [sch].[name] + '].[' + [tab].[name] + ']
			FOR INSERT, UPDATE, DELETE
			AS
			BEGIN
				IF SUSER_SNAME() <> ''''' + @ReplAccount + '''''
				BEGIN
					RAISERROR(''''Database is replicated and data cannot be modified!'''',16,1);
					ROLLBACK;
				END
			END'');

			'
		ELSE 'DROP TRIGGER ['+[sch].[name]+'].[trg_prevent_modify_'+[tab].[name]+']' + CHAR(13)
	END
FROM sys.tables AS tab
	JOIN sys.schemas AS sch ON tab.[schema_id] = sch.[schema_id]
WHERE tab.[type] = 'U'

PRINT @Stmt
EXECUTE(@Stmt)
GO

If you will test this solution the try to update the data in any table and the following exception will be generated:

Usually, you will capture this error in Replication Monitor as visible in this picture:

As a first step, we need to browse replication commands that are waiting in the distribution database to be replayed on subscribers. We will select these data from the Msrepl_errors table:

USE [distribution]
GO

SELECT 
	[id], [time], [error_code], [error_text], [xact_seqno]
FROM [dbo].[MSrepl_errors] 
ORDER BY [time] desc
GO

Once we have selected our error rising command the most important information is hidden in the xact_seqno column: it’s the starting transaction log sequence number of the first failed transaction in the execution batch.

We will use this sequence number as an input parameter for sys.sp_browsereplcmds stored procedure which returns a readable version of the replicated commands stored in the distribution database.

USE [distribution]
GO

EXEC [sys].[sp_browsereplcmds]
	 @xact_seqno_start = N'0x0000A31F0007BC9E01A200000000',
     @xact_seqno_end = N'0x0000A31F0007BC9E01A200000000'
GO

In the command column is the user-friendly text representation of the command to be replicated. The most important part of it is the number in parentheses which is in our particular case the primary key value of the row that should be deleted by this command. And because this row was deleted on the subscriber manually, a replication error is raised when this command is executed on the subscriber.

If we have the option to insert deleted rows on subscriber manually, replication will continue without an error and there is no need for subscription reinitialization.