0

我有一个关于使用 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 文件所在的文件夹结构。

任何帮助都会很棒。

4

2 回答 2

1

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

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

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

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

我也不赞成“从构建中排除”作为“删除”的替代方案；不久前，我看到了一个广泛部署该技术的项目；这使得从源文件中看到什么变得更难了，我现在认为“Build Action=None”只是“注释掉那些不起作用的位”对于 Snapchat 一代。

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

如果我的经验可以作为指导，那么 60 个构建错误不算什么；这些很容易由对不再存在的三个或四个对象的引用引起，并且可以通过热情地使用“删除”键将其放入源代码控制的垃圾箱。

于 2017-03-06T17:12:50.093 回答
0

您是否有一份可供使用的 SQL Compare 副本？如果没有，可能值得下载试用版，看看它是否适用于您的场景。

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

至少您需要指定以下内容： /scripts1: /server2: /database2: /ScriptFile:

于 2014-04-14T13:33:01.877 回答