Sql SSDT-不带dacpac的构建部署脚本

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

为了提供一些背景信息，我在VisualStudio2012中为我的数据库模式创建了一个项目。这非常有效，SSDT可以毫无问题地构建文件夹结构（函数、存储过程等，其中包含所有.sql文件）

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

我要寻找的是一种使用SQLPackage.exe构建部署脚本的方法，而无需生成dacpac文件。我需要在文件系统中使用.sql文件。VisualStudio将在不构建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文件所在的文件夹结构

---

任何帮助都会很好。

您有SQL Compare的副本吗？如果没有，那么下载试用版，看看它是否能在您的场景中工作，这可能是值得的

以下是可用的开关：

至少您需要指定以下内容： /脚本1： /服务器2： /数据库2：

---

/脚本文件：

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

把它们全部修好既不实用也不安全

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

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

我也不赞成将“排除在构建之外”作为“删除”的替代方案；不久前，我看到一个项目，在这个项目中，这种技术已经被广泛应用；这使得从源文件中很难看出什么起作用，我现在认为“Build Action=None”只是“注释掉Snapchat生成中不起作用的部分”

当然，所有这些的关键是源代码控制。这解决了剩余风险，即有一天您可能确实希望实现当前非工作过程的工作版本，使用非工作代码作为起点。它还消除了使用buildaction=None在解决方案中保留内容的需要，因为您可以简单地调用包含违规对象的代码的早期版本

---

如果以我的经验为指导，60个构建错误算不了什么；这些可能很容易由对三个或四个不再存在的对象的引用引起，可以通过使用“Delete”键将其扔进源代码管理的垃圾箱。

我认为在您的情况下不可能做到这一点。您可以选择不作为事务运行并尝试继续出错，但您最好的总体解决方案是从DB（或dacpac）导入并修复问题，或将这些问题对象标记为“非内部构建”。这需要一些时间，但是一个好的构建和干净的解决方案的好处将在长期内得到回报。谢谢Peter。目前SSDT显示了大约60个错误和大约200个警告，这只是一个代码库（我们有大约20个！）。所以你可以想象任务的规模。我想我们可以通过调整选项来减少它。当然，将一些设置为“非内置”是一种选择，尽管我认为我们最终可能会咬紧牙关，按照您的建议进行修复。您会惊讶于可以很快消除的警告数量。删除当前的数据库名（mydb.dbo.->dbo.）会有很大帮助，添加数据库引用通常会大大有助于解决这些问题。我确实知道规模-我们经历了约13个数据库，大多数具有交叉依赖性。这让人望而生畏，但可行。谢谢大卫。SQL比较绝对是一种选择。尽管它的成本很高，但我们很可能最终会修复所有生成错误。识别生成错误的一种方法是安装SQL提示符并使用查找无效对象功能。像所有的RedGate工具一样，SQL Prompt有一个完整的14天试用期。“巨大的成本”-您最好花在做其他事情上的时间成本是多少？不幸的是，这是一个许多老板都不理解的计算…@DavidAtkinson我想他们已经找到了无效的对象；这就是为什么他们在构建项目时遇到困难@GavinCampbell-那么DACPAC需要完全无对象无效吗？