add an option to ignore timestamp - binary 8 differences

tbsam

It is an option in sql replication to map rowversion/timestamp columns in the source database to binary(8) columns in the target replica database. It would be a nice option for sql compare to allow for this difference between databases, so you can easily see the differences between the source and replica target databases.
I know there is an feature in sql server replication to replicate schema changes but sometimes there are reasons why you don't want to enable this.
Without this option every table is flagged up as being different which is a headache.

Andrew F

An option to ignore certain columns during comparison is a feature we could implement in future. Upvoting this will help us prioritize it against other work:

https://redgate.uservoice.com/forums/14 ... in-columns

peter eh

I don't think this vote is the same as tbsam and me wanted - " ... an option whereby under each table, there is tick boxes ... - not an exclude on each table, I'm looking for one line like "tabledef: timestamp = binary(8)" and all these differences over lets say 500 tables are excluded. This would be really helpful and would save a lot of time by contrast with todays work. Today I have to click on every single table and deselect or unmap this field from the comparison. Hard and stupid work on big databases with over 500 tables.
Other useful excludes I can think of:
alldef: nvarchar(50) = varchar(50) -> meaning: excludes all differences with this expression in tabledefinitions, views, sp's, functions, ...
tabledef: nvarchar(length) = varchar(length) -> meaning: all table fields with the same name und the same number between the brackets are excluded from the difference viewer as long as there is no other difference. Useful for projects that migrate to unicode.
allname: tbs* = tbl* -> meaning: we are in the process of changing the table prefixes, exclude all differences that relate to these table prefixes.
...
Don't know if this is practicable, but it would be a lifesaver specially when you have thousands of database objects to maintain.
Peter