I use one-way transactional SQL Server replication to ship data out from a source server to multiple destinations, and recently added a publication with a vertically filtered article; that is to say a table where I exclude a column from replication because I do not want it sent to the subscribers.

I looked for confirmation as to whether you could run data validation on these subscriptions or not, to verify that the data matches between publication and subscription. For example you would normally do data validation on the publisher with this:

Exec sys.sp_Publication_Validation @Publication = 'Publication_Name', @RowCount_Only = 2

This calculates checksums and would normally display results like this:

Generated expected rowcount value of 8417 and expected checksum value of 87912378190 for TABLE_1.
Generated expected rowcount value of 249 and expected checksum value of 17733948456 for TABLE_2.

But also replicates that same command to the subscribers. When you next fire up your replication agent jobs they will have messages in the agent history describing whether the subscriber values matched the "expected" values from the publisher.

You must have the exact same column data types and columns in the same order from the publisher to the subscriber for the validation to pass, so in theory it shouldn't work on vertically filtered publications because you've excluded a column.

But it turns out it does work, with some caveats. It works because the internal call order of the stored procedures is something like this:

Exec sys.sp_Publication_Validation
Exec sys.sp_MsPublication_Validation
Exec sys.sp_Article_Validation
Exec sys.sp_msArticle_Validation
Exec sys.sp_Table_Validation @Table, @RowCount_Only, @Column_List

I included some of the parameters in that last call because the @Column_List is what is important. If an article has been vertically filtered the validation routines do a column by column checksum on the publisher to get the desired value, though only on SQL Server verions from the past decade or so, if that matters.

The caveat is that this does NOT work when you have extra columns on the subscriber tables. The reason for this is a problem in the way in which Sp_msArticle_Validation is written. While it generates a column list for Sp_Table_Validation on the publisher, when it saves the call for the subscriber it doesn't include a column list. You can verify it here.

So when it runs on the subscriber side, if you have extra columns, those are included in the checksum, and the validation fails. That's a big oversight in some situations and there doesn't seem to be a good way around it: not only am I not aware of any way to view the current Microsoft procedures, you can't edit them, and even if you write your own versions, it doesn't seem possible to even call some of them from your own procedures.

The only workaround would be to write your own validation routine to extract the articles and column names from your publications, call sys.sp_Table_Validation on the publisher with that column list, save the figures, and then run the same on all of the subscribers manually and compare the results. That's a lot of work.