Question

我有一个关于使用SSDT构建部署脚本的问题。谁能告诉我是否可以使用SQLPackage.exe构建部署脚本，其中源文件不是dacpac文件，而是使用.sql文件？

为了给出一些背景知识，我在Visual Studio 2012中为我的数据库模式创建了一个项目。这很好用，SSDT构建文件夹结构没有问题（包含所有.sql文件的函数，存储过程等）。

这就是问题所在 - 有问题的数据库来自遗留系统，并且充满了错误。我们不再关心这些错误中的大多数，并且将它们全部修复是不切实际或不安全的，所以多年来我们基本上忽略了它们。但是，这意味着我们无法构建项目，因此无法生成dacpac文件。现在，这并不妨碍我们进行模式比较并将数据库与文件系统（本地mercurial存储库）同步。但是，它似乎阻止我们构建部署脚本。

我正在寻找的是一种使用SQLPackage.exe构建部署脚本的方法，而无需生成dacpac文件。我需要在文件系统中使用.sql文件。 Visual Studio将生成差异的脚本而不构建dacpac，因此这让我觉得必须可以使用SQLPackage.exe之一使用其中一个参数来完成它。

这是一个SQLPackage.exe的例子，我想改编使用.sql文件而不是dacpac：

sqlpackage.exe /Action:Script   /SourceFile:"E:\SourceControl\Project\Database
\test_SSDTProject\bin\Debug\test_SSDTProject.dacpac" /TargetConnectionString:"Data 
Source=local;Initial Catalog=TestDB;User ID=abc;Password=abc"  /OutputPath:"C:
\temp\hbupdate.sql" /OverwriteFiles:true /p:IgnoreExtendedProperties=True     
/p:IgnorePermissions=True /p:IgnoreRoleMembership=True /p:DropObjectsNotInSource=True

这很好用，因为它使用了dacpac文件。但是我需要将它指向.sql文件所在的文件夹结构。

任何帮助都会很棒。

Answer 1

正如评论中所建议的那样，我认为咬紧牙关并修复错误是前进的方向。你说

将它们全部修复是不切实际或不安全的，

但我认为你应该多考虑一下。我最近遇到了类似的情况，从中出现的关键是要意识到与删除程序和函数相关的操作风险一旦被调用就会抛出异常零。

请注意，如果这些对象不构建的原因是它们包含生产中但不存在于项目中的跨数据库或跨服务器引用，则不适用;这完全是一个单独的问题，但也是一个可解决的问题。

我也不赞成“从构建中排除”作为“删除”的替代方案;不久之前，我看到了一个广泛部署这项技术的项目;它让人们更难看到源文件中的内容是什么，而我现在认为“Build Action = None”只是“为了那一代而评论出不起作用的部分”。

当然，所有这一切的关键是源代码控制。这解决了有一天您可能确实想要使用非工作代码作为起点来实现当前非工作过程之一的工作版本的剩余风险。它还避免了使用Build Action = None来保持解决方案中存在问题的必要性，因为人们可以简单地召唤包含违规对象的代码的早期版本。

如果我的经验是任何指南，那么60个构建错误就不算什么;这些可能很容易引起三个或四个不再存在的对象引起，可以通过热情地使用“删除”键将其委托给源控件的垃圾箱。

Answer 2

您是否拥有SQL Compare的副本？如果没有，可能值得下载试用版以查看它是否适用于您的方案。

以下是可用的开关： http://documentation.red-gate.com/display/SC10/Switches+used+in+the+command+line

至少你需要指定以下内容： / scripts1： /服务器2： / DATABASE2： /脚本文件：

SSDT - 在没有dacpac的情况下构建部署脚本

2 个答案: