DACPAC与数据层应用相关的最大问题是如何将DAC的更新发布到SQL Server。这通过一个临时名称创建新数据库，在数据库中生成新的对象，然后将现有数据库中的数据移动到新数据库中来完成。在所有数据被转移后，运行既定的脚本，现有的数据库被删除，新数据库更正为其名。

　　这种发布技术导致数据库至少需要两倍的数据空间，以及足够的日志空间至少能容纳目标数据库事务日志中的最大对象。例如，你的数据库是5 GB、最大数据表是500 MB，你需要能够容纳5 GB数据库和能够容纳500 MB数据表的事务日志的磁盘空间。

　　这项技术有几个问题。首先，你的事务日志变得毫无用处，这是因为数据库被重命名，在数据库的升级过程中不能恢复事务日志。

　　另一个问题是如果在数据库中使用SQL Server的Service Broker，升级过程队列中的所有信息会丢失，在升级过程发布之后、完成之前数据表中所做的任何数据更改也会丢失。

　　现在可以为一个现有的数据库开发DACPAC以使得它并不仅仅为新项目所使用，但并非所有的数据库都可以成功地转换为DACPAC。

　　为什么要使用数据层应用程序呢?

　　看完这一切，第一个问题可能就是为什么还要使用DACPAC?答案很简单，即SQL Azure。也许你已经意识到DACPAC支持的特性与当前版本的SQL Azure的特性相当吻合。由于少量数据可以通过Azure适配到数据库(1 GB或10 GB，取决于购买的数据库大小)，所以使用SQL Azure，你不必担心备份，这已被此方案的冗余技术所解决。

　　只要你能根据DACPAC平台的条件工作，为SQL Azure数据库设计的数据层应用完全能够被用来处理本地的内部数据库。

　　由于DACPAC系统所使用的发布技术，建议您不要为Tier 1应用程序或者为SQL Azure支持的大于10GB的数据库应用程序使用DACPAC。这样做将在新旧数据库间移动数据的升级过程中需要更长的停机时间。

　　显然微软还没有作出有关DACPAC第二版的任何通告，这一版本据说能够支持SQL Server 2008 R2的其他功能集并允许DACPAC去支持微软SQL Server的早期版本。