Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Starting Team Development of Non-Microsoft Databases

Starting Team Development of Non-Microsoft Databases

Visual Studio 2010

You can obtain database schema providers (DSPs) from vendors other than Microsoft that will enable you to manage development of databases other than SQL Server 2008 and SQL Server 2005. Each developer on your team must install the non-Microsoft (also known as third-party) DSP if they want to work with the database project that uses that DSP. In addition, you must also install that DSP on each computer where you want to use Team Foundation Build to build database projects that use that DSP.

A database project contains the object definitions and deployment scripts that you would need to create a separate instance of that database or to update an existing instance. Because a database project is an offline representation of the database, you can put it under version control and then deploy iterative changes to an isolated development environment. Team members can test their changes independently and then share those changes with the team after they are fully tested. By taking this approach, you help control the quality of the database code before you deploy it to a production environment.

When you create a database project, you specify the type of project that corresponds to your DSP. The DSP creator provides one or more templates that appear in the New Project dialog box for their DSP. For a list of the non-Microsoft DSP offerings that are currently available, see Development Edition Home on the Microsoft Web site.

Database project properties are specific to the type of DSP. In addition, each DSP defines the specific feature extensions that are supported for that DSP. For example, a DSP for database X might support different types of refactoring than the DSP for database Y. The following feature extensions are specific to each DSP:

  • Refactoring Types and Targets

  • Data Generators

  • Code Analysis Rules

You can use these feature extensions only if the DSP implements feature extensions to those features for their DSP.

The object types that appear in Schema View are specific to a particular DSP. You cannot compare the schemas (or the data) of database projects or databases that use different DSPs. The organization of the files within the database project is also specific to a particular DSP.

All DSPs can support the following operations, depending on the support that was implemented by a particular DSP:

  • Import objects and settings

  • Import script

  • Build

  • Deploy

  • Database Unit Tests

  • Schema Compare

  • Data Compare

For more information about the specifics of your DSP, see the documentation that accompanied your DSP.

Common Tasks

Supporting Content

Learn more about database projects: You can read about the basic concepts of how to manage schema changes by using database projects.

Put an existing database schema under version control: You can create a project, configure project settings, and import a schema by using the database project wizard. You can also create an empty project if you want to import the schema later or if you do not have permission to access the database from which you want to import the schema. After you import the schema, you can add the project to version control.

Starting Team Development of Databases

Describes how you create an offline representation of a database schema in a database project and add the project to version control.

Starting Team Development of Databases that Reference Other Databases

Describes how you can create an offline representation of a database schema, define one or more references to other databases, define variables for target deployment environments, and add the project to version control.

Starting Team Development of Databases that Reference SQLCLR Objects

Describes how you can create an offline representation of a database schema, define references to assemblies that contain SQL common language run-time (CLR) objects, define database objects that reference those objects, and add the project to version control.

Starting Team Development of Large Databases

Describes how you can create an offline representation of a database schema, spread across multiple projects, to restrict access to parts of the database schema. You can also use this approach to improve performance if you work with large databases.

Starting Team Development of Databases that Reference Shared Server Objects

Describes how you can create an offline representation of a database schema, define references to a shared server project, add references to objects that are defined in the server project, and add the database project to version control.

Starting Team Development of Databases that Use XML Schema Collections

Describes how you can create an offline representation of a database schema, reference an XSD schema, and use that referenced schema for typed XML columns in your tables.

Merging Multiple Databases into a Database Project

Describes how you can take objects that are defined in multiple databases and merge them into one database project.

Community Additions

ADD
Show:
© 2015 Microsoft