Also very disappointed. There are a number of times that this has meant that I have back to do the sync by hand because I couldn't separate the triggers from other changes to the table.

Very disappointed to hear this is considered too much effort.

This request has my vote as well. Certain SQL replication strategies utilize DB artifacts (in particular DML triggers) that would be really nice to be able to isolate and ignore in compares with other DBs without having to ignore ALL DML triggers.

Anyone know if this was every implemented?

actually it should be handled the same way as in Oracle source compare. a trigger is a different entity than a table. They should be in separate files

Not having the ability to filter out certain DML triggers means my company is now evaluating Apex SQL Diff which does.

Currently evaluating SQL Compare 13 in a merge replicated environment.
Being unable to filter out triggers starting with "msmerge" is a show stopper. These triggers are different (both name and content) on all subscribers.

This functionality is strongly required. For example to filter audit, custom replication or some client specific triggers.

Please add this functionality, it is a serious drawback to using the product.

Yes please. A good portion of our database is vendor-controlled, so we do not actually source control nor deploy schema changes. However, we often need to add or modify triggers that we own on these tables, and use SQL Compare for creating deployment scripts - those then have to be modified to keep just the trigger portion, etc. I would like to be able to just compare and build a script for triggers.

SqlTableDependency creates transient DML triggers that then appear as diffs - would be very useful to be able to exclude these

Please fix this. It makes no sense to handle triggers as part of the table without being able to exclude them.

Filter on the name of the DML Triggers to be able to separate triggers of a replication tool and own created triggers.
For this the DML triggers need to be handled as separate objects within SQL Compare. Then they could be filtered upon.

I agree with both triggers and indexes being separate objects. I think this will better manage the objects and keep the complexity down. I compare to a scripts folder which is then put into source control and if I have a lot of changes tables with many indexes and/or large triggers get their scripts scrambled and the resulting scripts will not work even to try and re-compare requiring manual intervention to find and delete the offending scripts to try again with smaller groups of changes.

Indexes should also be separate objects.