Allow me to specify a subset of columns for static data like I can in SQL Data Compare
I do not want to source control certain columns in my reference tables (e.g., update date/times since these are different on each server and get set by a DEFAULT).
Jon Baggaley commented
This is particularly annoying for us as we have a table containing identity values of policies which are set (design before my time) and every time we create a new policy whilst working on our dev version, the numbers naturally increment. We have no interest in saving the changes of this static table so would like to exclude changes after the initial version.
Wade Tatman commented
The product really needs this one! My commits are constantly littered with data updates due to timestamps changing (automatically via trigger). I don't even use SQL Data Compare because of this, as it would wreck my audit data in production. Source control would benefit by being faster too.
I figure that SQL Data's engine is being used for the static data comparison, so why not give the ability to customize which columns are compared? (this is a pretty old request so maybe it's there..that would be awesome)
Phil Helmer commented
Is there any update on this? We are having to add a lot of steps to our process because this feature is missing. Granted, SDC can do the work, but now we are forking our work by tool (1 method for schema, 1 for data) instead of usage (1 method for the "always like this" items and another for the "where are we deploying it?" items).
Paul Jenkins commented
I don't know of an orgranization that does not require audit columns on all of their lookup tables (static data). Not having the ability to do this makes the static data mechanism useless for organizations with auditing standards.
Corrin Lakeland commented
Hi, just wondering if anything happened with this now static data is live?
Jason Duffett commented
The problem we have is that the current EAP builds of SQL Source Control aren't usable because of the limited data support.
We use the tools in the following way:
1. A single SVN repository
2. SQL Source Control for developers to check-in changes to this source tree.
3. Custom SQL Compare and SQL Data Compare scripts to deploy changes from the repository to our test, staging, production environments
Testing we've done with the pre-release SQL Source Control have failed because it always tries to overwrite the data in the repository.
We won't be able to use the new release unless either we can completely disable data support in SQL Source Control, or the data support is enhanced to allow us to specify which columns to source-control.