I have happily been writing a product which uses a, Sql Server Database Project and life has been good until we discovered a problem in upgrades.
While we create tables, stored procedures and various other database artefacts, once deployed at customers they can add their own columns to the tables created by our dacpac.
We are using DacFx for deployment (Microsoft.SqlServer.Dac) and also provide the raw dacpac for customers who insist deployment by their DBA's.
While the problem may still be present when using SSMS or similar tools, I am certain that with the "right" code we should somehow be able to prevent this when deploying via code.
Has anyone had the same issues and possibly found a solution?
Update, add screenshot for deployment settings. As can be seen in the image, the "Drop objects in target but not in project" setting is already turned off.
Dacpac deploys will NOT by default drop objects it finds in the target database that do not exist in the source. This means just deleting a table in SSDT will not try to drop it on a deploy. This does not apply to columns.
Monday, 20 April 2020 [ColumnToRemove] is being dropped, data loss could occur. This happens due the fact that my source table changed/removed a column that's still available in the target table. Uncheck - 'Block incremental deployment if data loss might occur' checkbox.
What is a DACPAC? A DACPAC is a data-tier application package in the form of a windows file containing all the database structure into one unit.
A DACPAC is a single deployment file that contains your entire database schema and some related SQL files (like look-up data), basically, everything to deploy a new version of your database in one file. It is similar to a BACPAK, which is a DACPAC plus all of the data in every table (like a standard database backup).
Love this statement "I have happily been writing a product which uses a, Sql Server Database Project and life has been good" ha ha!
You could write a deployment contributor that looks for new columns and remove the drop step from the process.
You can either write your own or I have one that should do it (http://agilesqlclub.codeplex.com/), if you use my one then this will probably work for you:
/p:AdditionalDeploymentContributorArguments="SqlPackageFilter=KeepType(.*Column.*)"
If you want to write your own then you can use mine as a guide (source is on codeplex) or see http://blogs.msdn.com/b/ssdt/archive/2013/12/23/dacfx-public-model-tutorial.asp specifically "Solution 2: Filtering at deployment time".
Ed
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With