Source Control Data (Data folder is blank)
would be awesome if it scripted the data as well
Support for selection tables with data versioning.
We need this for data collections versioning (eg. list of countries, user roles,...)
I've got a small number of manually created dimension tables. It would be pretty cool if I could include the DML for those tables in version control. I know you have a full product that would probably do a better job here, but I'm looking for a simple solution for small volumes of data
We have application data that's the same for all database. Would be nice to commit certain table data to subversion.
Something cool would be able to allow tables to have data sourced. Maybe a right click and an option to source out the table's data. Then that goes into the data folder in TFS as insert scripts. Obviously, some tables we wouldn't want data sourced. If someone changes the data, it has to be checked in.
Add the possibility to track changes to data (records).
SQL Source Control v2.0 is now available with support for source controlling your static lookup data from within SSMS. For more details, see http://www.red-gate.com/MessageBoard/viewtopic.php?t=12947.
If you’ve been using SQL Data Compare Pro to source control your data in the “Data” folder, then please contact firstname.lastname@example.org to keep your history.
If you need any advanced features, like only source controlling a subset of columns or limiting the rows with a WHERE clause, then you will need to continue to use SQL Data Compare Pro, http://www.red-gate.com/help/SourceControlData.html.
Mike Rankin commented
What I really want to be able to do is to add a developer to my team and tell them to pull their local database from svn. I want it to be in a ready state after it has been linked and they have done the "get latest" thing. I don't mind using some of the other redgate tools to get the static data put in to source control, but I would really like the developer to be able to get the database and the data without the use of another tool.
I think this would be a very very useful addition and probably the only feature which is make me resistant to purchasing as an addition to our CI process.
Will keep an eye on this space for any news.
This would be a tremendously useful addition.
There needs to be a way to designate a table as "static/reference" - perhaps using extended properties or something under the covers, but right-clicking a table in a source-controlled DB should give you the option - you may also want to give the option to mark a schema as "static/reference" so that any table in that schema ends up in source control - data and all. I do agree, though, that the last thing you want to do is commit your transactional data to source control, so this feature needs to be implemented carefully
Renko Karman commented
The schema and static/reference/lookup data both HAVE to be kept in source control! The business logic depends on the database schema to be correct as well as your static data to be correct. You don't want to create the schema every time you run your application and just the same you don't want to check (and add if non-existing) your static data evey time your run your application.
However, tables containing transaction data should never end up in source control. As mentioned before you don't want your source control to be misused as a backup program. So you should be able to only "opt-in" on tables that need version controled data.
In my opinion this product is not mature without this feature and could not claim to be a full solution to the database source control problems we all face.
patrick feenstra commented
i would like to see to be able to store data from static data tables
I think Stephanie nailed the use case. You wouldn't want to script all data in an entire database, but it is very useful to have static data stored in version control.
Dave W commented
Yikes! I agree that this is really not a feature we need or want in a source control product.
If there is static/reference data that an application depends on, then it should be scripted and included in the deployment project, and that project should be handled in it's own repository. Apparently Data Compare Pro scripts data, but SSMS scripts data very easily as well.
The last thing I want is to be able to hit "committ" without thinking and send my machine off on a task of scripting millions of records in a table. That's why we have databases.
I'd absolutely like to see a data control built into SQL Source Control. Lots of my apps have a start set of data in some tables which will then be built upon. Being able to select the data to be checked in and then keep it in source with one easy tool would be great.
Dave Sussman commented
I too want this feature, as using Data Compare and checking in using TortoiseSVN is a disconnect. For example, if I do a table change that requires a data change, I can commit the table change with SQL Source Control, but the data would then have to be scripted out and committed separately; three distinct actions instead of one.
AdminRogerHart (Admin, Redgate) commented
You can find some information on using SQL Source Control and SQL Data Compare together to source control data here:
Please dont do this. How do I vote things down? Being able to take a whole database out of db security onto a file share is a hideous idea. SQL Data Compare moves data between database should you need to. SQL Backup secures your data for business continuity. SQL Source Control is specifically for managing database object changes. please.
ash flynn commented
This would be very useful for us. We have tables that hold data that is key to our applications. For example a row in a table may be a page on a website. So if we had to option to commit data changes on specified tables it would be invaluable to us
gregor suttie commented
Eugene - sometimes its nice to roll back one table data, I know you can use sql compare to do this but sometimes its quite handy to have say a lookup tables data scripted and handy to send to someone if they require it - again I know Sql Data Compare can be used but it would be a very cool addition in my opinion.
I use Sql Packager for this task but hardly anyone knows you can do this <g>
SQL Source Control does not replace database backups. Backups should be used for transactional data. I think we're talking about source controlling static/reference/look up data, which is a part of your database deployment that your application depends on.
Eugene Niemand commented
Isn't this why you would keep a database backup or am I missing the plot?
AdminRogerHart (Admin, Redgate) commented
In the meantime, some of the procedures in this support article might be able to be adapted for use with SQL Source Control:
Is there a standard practice about where to store Static/Reference data?
This is something that we are considering in a future version so that your static/reference data could be source controlled along with your database schema. If you have SQL Data Compare Pro 8 (http://www.red-gate.com/products/SQL_Data_Compare/index.htm), you can script your static/reference data to a folder and then check this in using Tortoise SVN. We hope to write a whitepaper about this soon.