Question

We have two databases, A and B. A contains tables that should also be deployed to B; however, A should always be considered as the master of those tables. We don’t want to duplicate the schema object scripts. We do not want to simply reference A’s table from B – they need to be separate, duplicated tables.

As far as I can see, there are two ways to achieve this:

1. Partial projects: export the shared schema objects to a partial project (.files) file, and import it into the B’s database project

2. Adding shared schema object files to the B’s database project as links.

These both have the disadvantage that you need to explicitly specify files – you cannot specify a folder, meaning that any time a schema object that needs sharing is added to A’s database project, then either the partial project export would need to be run again, or the new file added as a link to B’s project.

What are the advantages and disadvantages of these techniques? Are there any better ways of achieving this that I may have missed? Thanks.

Answer 1

Partial Projects are not supported in the VS2012 RC release, which makes me think that I shouldn’t use them. Furthermore, it appears that Composite Projects within SQL Server Data Tools (SSDT) may be the long term solution.

I’ve discovered that it is possible to link to entire folders by editing the dbproj file manually. For example:

<Build Include="..\SourceDatabase\Schema Objects\Tables\*.sql">
  <SubType>Code</SubType>
  <Link>Schema Objects\Tables\%(FileName).sql</Link>
</Build>

This works quite nicely, so it will be our preferred solution until we evaluate SSDT. The main drawback that I’ve found with it so far is that it will include all files in the source database’s folders, including those that are not included in the source database project.