Question

I am using a VS2010 database project, and want to be able to load:

• Reference data into any instance (isolated development, test, … production)

• Test data into development and test databases only.

As I understand it, reference data is no problem, I use scripts into a post-deployment script, which will be run unconditionally.

For test data, I understand I should use a data generation plan; and that I can use a data bound generator to load data from a data source such as Access, Excel or a text file. MSDN has a walkthrough on generating test data from an Excel spreadsheet, which at first glance looks like what I need, but it uses an absolute path to reference the Excel file. Which doesn’t seem to be compatible with having the database project in source control, accessed by different users who may have their workspaces at different locations.

What is the “best practice” for loading test data in this situation? Can I use a relative path in the connection string and be sure it will always be interpreted in the same way on all developer machines?

I was expecting to find a syntax something like the |DataDirectory| substitution string that would allow a path to be specified relative to the Database Project directory.

Answer 1

On further reading, I think a data generation plan is the wrong tool for this scenario.

What I’m doing now is creating a post-deployment script with the test data, then making sure it is executed conditionally by using SQL command variables. Each deployment target (isolated development; UAT; PROD) can have its own SQL command variables file (.sqlcmdvars), which will control whether the script is run.

E.g. to load test data only for the IsolatedDev database, I can use the following in a post-deployment script:

IF '$(DatabaseName)' = 'IsolatedDev'
BEGIN
    ... insert statements to add test data
END

and be sure the test data won’t be inadvertently loaded into a production database.

Please feel free to chime in with experiences and best practices.