Options
Ignoring field differences with SQL Compare
Justin Spindler
Posts: 18
I believe I may have asked about this kind of functionality in the SQL Toolkit 4.x forums some time ago. It does not appear that the situation has changed but I figured that it wouldn't hurt to ask.
My company is currently making use of SQL Toolkit with SQL Compare in order to distribute database schema changes to our clients when they upgrade our software. This is working quite well.
My company has always had the policy of permitting our clients free reign within the product database. This includes the ability to add their own fields, triggers or indexes to tables required by our application. Understandably SQL Compare wishes to dispose of these items as they are not found in the source schema.
I've currently worked around this issue by employing reflection in order to trick SQL Compare into thinking that the field, index or trigger exists in both schemas so that it effectively ignores the difference. This is a flimsy solution as it is possible that you may change the internal structures of your classes and break the code.
I was curious if there is currently a method through which to carry out this functionality or if this may be expected in a future version?
Thanks,
Justin Spindler
My company is currently making use of SQL Toolkit with SQL Compare in order to distribute database schema changes to our clients when they upgrade our software. This is working quite well.
My company has always had the policy of permitting our clients free reign within the product database. This includes the ability to add their own fields, triggers or indexes to tables required by our application. Understandably SQL Compare wishes to dispose of these items as they are not found in the source schema.
I've currently worked around this issue by employing reflection in order to trick SQL Compare into thinking that the field, index or trigger exists in both schemas so that it effectively ignores the difference. This is a flimsy solution as it is possible that you may change the internal structures of your classes and break the code.
I was curious if there is currently a method through which to carry out this functionality or if this may be expected in a future version?
Thanks,
Justin Spindler
Comments
I remember that cunning trick from a few months back where you get access to the redgate.sqlcompare.engine.table object using reflection and lop columns off that you're not interested in. As far as I'm aware, we haven't changed the engine to support treating columns as objects in their own right. The columns in the table object are still fixed and can't be ignored the way, say, that indexes can be ignored.