We are deploying our database model (vs db project) to several customers via a setup routine. Internally a dacpac process is responsible for the upgrade process, if an already existing installation will be upgraded. Our customers uses SQL Server 2012 up to SQL Server 2017, but our codebase has to maintain the least common feature. eg. STRING_SPLIT isn't useable, because it was introduced in SQL Server 2016.

My idea is to have target specific T-SQL funtions which are deployed depending on their target system. If target system equals SQL Server 2016, than STRING_SPLITT, else self made solution is taken.

any ideas?


As per MSDN BOL Here In general, DAC tools are capable of reading DACPAC files generated by DAC tools from previous SQL Server versions, and can also deploy DACPAC’s to previous versions of SQL Server. However, DAC tools from earlier versions cannot read DACPAC files generated by DAC tools from later versions. Specifically:

1. DAC operations were introduced in SQL Server 2008 R2. In addition to SQL Server 2008 R2 databases, the tools support generation of DACPAC files from SQL Server 2008, SQL Server 2005 and SQL Server 2000 databases.

2. In addition to SQL 2016 databases, the tools shipped with SQL Server 2016 can read DACPAC files generated by DAC tools shipped with SQL Server 2008 R2 or SQL Server 2012. This includes databases from SQL Server 2014, 2012, 2008 R2, 2008, and 2005, but not SQL Server 2000.

3. DAC tools from SQL Server 2008 R2 cannot read DACPAC files generated by tools from SQL Server 2012 or SQL Server 2017.

Hope it will help out to you.


The dacpac target platform SQL Server version is determined at build time so newer features cannot be used unless you manage and deploy those with custom code. You can deploy a dacpac built for an older SQL Server version to a newer one but not visa-versa. This assumes you include the latest DacFx version included in your setup program.

One approach to facilitate a different code base for each target SQL version is with separate source control branches. Another method would be composite projects, with the SQL version specific code in separate projects. All of these add complexity the development, build, testing, and deployment processes so I suggest you stick to common features except in cases where the newer feature adds significant business value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.