locked
DacServices: Ignore Schema During Deployment RRS feed

  • Question

  • We currently ship a set of database scripts with our application that are applied programmatically to create and/or update our database during installs or upgrades.  We'd like to simplify the maintenance of these scripts by including and programmatically deploying a dacpac (we'd manually script data transformation, where necessary, but let the dacpac drive creating/modifying/dropping objects).

    To allow our clients to create custom objects within our database, we ignore all objects within a schema named "reserve", which is complicating our move to SQL Data Tools.  As far as I can tell, there is no way, specifically using DacServices/DacPackage/DacDeployOptions, to basically say "drop objects not in source, but only those belonging to schema XYZ."  Can somebody confirm that this is correct?  Are there any plans to add such a feature? 


    Tuesday, July 30, 2013 9:26 PM

Answers

  • As far as I'm aware we don't support filtering by schema.

    If you are willing to write some code this is a great candidate for use of a deployment plan modifier. These let you programmatically alter the deployment plan after it has been generated. In this case, you could write code that removes any DropElementStep where the TargetElement's Name starts with "reserved". 

    • Marked as answer by Travis Troyer Wednesday, July 31, 2013 12:38 PM
    Tuesday, July 30, 2013 10:48 PM

All replies

  • As far as I'm aware we don't support filtering by schema.

    If you are willing to write some code this is a great candidate for use of a deployment plan modifier. These let you programmatically alter the deployment plan after it has been generated. In this case, you could write code that removes any DropElementStep where the TargetElement's Name starts with "reserved". 

    • Marked as answer by Travis Troyer Wednesday, July 31, 2013 12:38 PM
    Tuesday, July 30, 2013 10:48 PM
  • Thank you for the prompt feedback... 

    The deployment plan modifier sounds like a decent solution, so it looks like we'll be headed in that direction. 

    Wednesday, July 31, 2013 12:45 PM