New feature: Disable auto-mapping of similar columns

Andrew F

We have added a new feature to SQL Compare 12: the ability to toggle the automatic mapping of similar columns. This is in response to feedback that the default behaviour (to always map similar columns) was undesirable in some situations. The new option can be found on the project Options tab under Auto-map similar columns:



By default SQL Compare automatically maps columns having the same data types and similar names. This is to help detect renamed columns without the user having to map the columns manually.

The new option is selected by default so there is no change in behaviour for existing projects. To disable automatic mapping, un-check the option and click Save. When disabled, columns that SQL Compare would have mapped together automatically will now have to be mapped manually from the Table mapping tab.

The new option is available via Frequent Updates in SQL Compare V12.0.37 and later.

We would like to know whether this feature addresses your concerns about the immutability of the previous behaviour and if there is anything more we can do to improve this.

jmeyer

I definitely like the new feature

pmoore

Thanks for adding this feature. I've just upgraded so I can take advantage of it.

pmoore

>> if there is anything more we can do to improve this.

Not sure if this is the right place to make related suggestions.. But it would be great if we could limit the object types to be filtered and compared before opening a project.

I'm trying to compare a handful of tables which need to be mapped manually and my source db has 45,000 objects (7500 tables and 36,000+ CLR's). Each time the project refreshes it takes 10-15minutes.

This is frustrating because I only want to compare the table schema and datatypes for fields with matching names.

sam.blackburn

It tends to be the registration, rather than the mapping operation itself, that is taking a long time; it sounds like you need some sort of partial registration of your database. This is a tricky problem because SQL Compare needs to identify any objects that depend on your few objects of interest, and it's difficult to catch all of these without processing every single object. There are some caching features we could borrow from the SQL Source Control, where we assume certain parts of the database haven't changed, but they can break in various cases such as a recently restored backup. We'll keep scratching our heads!

Charles71

One of the best features in long time. I am using it frequently and it is really helpful. I was thinking the other day how to improve it and... I think that, so far, it is just perfect. Thanks!