What three improvements would you suggest for DBPro setup process?

1. Data Generation: To allow for "Test Data AS IS" to be Checked-In, Checked-Out, Shelved and Deployed- similar to Data Generation plans.

Thanks,

Thanks for the feedback. This is not really a setup feauture change though :)

How would you want to deal with the AS-IS test data Are these script file with INSERT statements BCP files that you load with BULK INSERT

Both of these you can make part of the project today through the post deployment scripts.

If you are looking at the ability to merge data (INSERT/UPDATE or DELETE) with existing data this does not exist today, I see how you would want that to deploy data that is part of your schema but not for test data.

Also you could simply RESTORE a database for you Unit Testing.

-GertD

Thank you for you reply and I am glad that you are taking an interest in this feature.

Applicatively, these are some of the uses I had in mind are:

- All developers can work with the same data.

- If data is damaged it can be can restored.

- Restore a specific version of the data

- Getting more realistic, than Generated, Test Data.

- Manage changes(Versioing) in System Tables, Parameter Tables, "Slow changing" Tables, Aplication Configuration Tables managed in DB. - these are practically code

- Provide a basis for duplicating a "good data base".

- Add and preserve new use cases.

Implementation wise:

- I was thinking mostly in terms of managing Changes and Development needs, rather than Deployment.

- I guess generating Insert or Update statements will do it (I don't assume it is trivial)

- One of the things I did in the current version(to avoid the tedious work of building Generation Plans): I imported a DB. I then deployed an empty DB. I compared(selectively) the 2 DBs and Populate the empty DB with the Update. Thus, I duplicated the DB data from the imported.

Israel Brill

If you think about Data Compare and its ability to generate data diff scripts; and imagen you make this part of the build system, so you can generate a data diff script as part of the build; how much would that address your needs

1. So you would keep the source data inside your project.
2. During build we would compare this data with the target, the same way would do this for schema and generate diff script
3. Deployment would execute the data diff script
4. The result being that you have updated the information inside the table on the target to match the data in the project

This could be one approach. An other would go like this.

1. You define the data inside your project and store it inside an XML file, this will allow us to associate an XSD, so it there is a change we need to make because the underlying table structure changed, we can potentially update the data file as well in a structured fashion
2. You alwas deploy the full data file and you would generate diff grams on the fly (same style ADO.NET does this in a DataSet) and push the data changes to the target at that time

BIg difference between the two: how much data do you push when. In option 1 you only push the diff; in 2 your push everything and but you are less vunarable for changes occuring between the build and the deploy, which might be a bigger issue with pushing out data changes.

An other related issue is; what to do with records that do not exist in the stock data that you made part of the project. Do you need to keep then or delete them. We are actively thinking about all of this, please keep the input coming, it helps us prioritize options.

-GertD

I tink I found a specific case of my request at the following thread: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=896489&SiteID=1&PageID=1

I think It is a matter of taking the view of looking at (static/slow changing) data as code.

It seems, that as the thread above developed, it reached the need for versioning the data, i.e. manage the changes through the source control.

Israel Brill

The purpose of my response was to solicit feedback on possible ways to implement this and requirements, we already know we need to provide a solution for this better then what you have today in the form of version script files with INSERT, UPDATE and DELETE statements. I would appreciate feedback on these options raised.

-GertD