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

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.

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.

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.

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.

You can find some information on using SQL Source Control and SQL Data Compare together to source control data here:

http://www.red-gate.com/supportcenter/Content.aspx?p=SQL%20Source%20Control&c=SQL_Source_Control/help/0.2/SSC_Source_Controlling_Data.htm&toc=SQL_Source_Control/help/0.2/toc.htm

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.

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

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.

Isn't this why you would keep a database backup or am I missing the plot?

Very similar to http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/457874-data-folder-is-blank

In the meantime, some of the procedures in this support article might be able to be adapted for use with SQL Source Control:

http://www.red-gate.com/supportcenter/Content.aspx?p=SQL%20Data%20Compare&c=SQL_Data_Compare/help/8.0/SDC_WE_Static_Data_In_Source_Control.htm&toc=SQL_Data_Compare/help/8.0/toc70005.htm

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.