问题标签 [data-tier-applications]

前言

我使用数据层应用程序项目和 SQL CLR 数据库项目来管理我的应用程序的数据库部分。
我有 3 台不同的机器（相应地用于本地、dev/ci/qa 和 preprod/prod 部署环境）应该安装数据库部分。
在 PostDeployment 脚本中，我创建 CLR 存储过程（带有程序集）以及登录名和用户。
登录名和用户应根据配置不同。

问题

我在使用变量时遇到问题。这是我尝试过的 PostDeployment 脚本

和

以下是我添加登录名、用户 (AddLoginsUsersRolesDev.sql) 的方法：

对于 PostDeployment.sql 操作是 PostDeploy 并且 SQLCMD 模式已打开，对于包含脚本操作不在构建中。
部署失败，出现“SQL 执行错误：发生致命错误。找不到变量 MSBuildProjectDirectory”。
据我所知，在数据库项目中，我可以为此目的使用 Database.sqlcmdvars。我应该如何解决这个问题？

更新

我已经添加

到 .dbproj 文件并创建 Database.sqlcmdvars：

这行不通。

我已经添加

这也行不通。

我已经添加

这也不起作用（在某处我读到可能的 MSBuild 变量应该与 sqlcmd 同名）。

我已经在 PostBuildEvent 部分之前导入了 SqlTask​​s.targets 项目。
前：

后：

这也行不通。

谢谢。

我在 Visual Studio 中将新的 SQL Server 工具与数据层项目一起使用。我创建了一个快照 (.dacpac)，并尝试将其部署在管理工作室的 SQL Server 实例上，但出现以下错误。有什么线索吗？

我的 dacpac 文件和 SQL Server 都是本地的。

使用 VS2010 SP1 数据层应用程序项目，我创建了最简单的数据库：

CREATE TABLE [dbo].[Table1] ( column_1 int NOT NULL, column_2 int NULL )

然后，我成功构建了 .dacpac，并通过使用 SSMS 2008 R2 将其部署到本地 SQL Express 实例来验证它（一切正常）。

然后我尝试使用 SSMS 2008 R2 将 .dacpac 部署到 SQL Azure 服务器。该向导设法完成了每一步（包括创建数据库和创建模式），但在最后一步 - “在 DAC 元数据中注册 DAC” - 出现 IndexOutOfRangeException（见下文）失败。

我尝试针对现有的 SQL Azure 服务器、新的 SQL Azure 服务器（均因相同的异常而失败）以及具有同名空数据库的 SQL Azure 服务器（此服务器因 SSMS 运行时异常而失败）执行此操作）。

我现在没有主意了。任何关于如何将 .dacpacs 部署到 SQL Azure 的想法都将不胜感激。

System.IndexOutOfRangeException：索引超出了数组的范围。在 Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetDbComparer(Boolean inServer) 在 Microsoft.SqlServer.Management.Smo.SqlSmoObject.InitializeStringComparer() 在 Microsoft.SqlServer.Management.Smo.SqlPropertyMetadataProvider.PropertyNameToIDLookupWithException(String propertyName, PropertyAccessPurpose pap) 在 Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetDbComparer(Boolean inServer) 在Microsoft.SqlServer.Management.Smo.AbstractCollectionBase.get_StringComparer() 在 Microsoft.SqlServer.Management.Smo.SimpleObjectCollectionBase.InitInnerCollection() 在 Microsoft.SqlServer.Management.Smo.SmoCollectionBase.get_InternalStorage() 在 Microsoft.SqlServer.Management.Smo。 Microsoft.SqlServer.Management.Smo.DatabaseCollection.get_Item(String name) 上的 SmoCollectionBase.GetObjectByKey(ObjectKeyBase key)。

在我们的应用程序数据层中，我们完全依赖存储过程和 Web 服务进行数据交换。我们在大量页面中使用如下代码来执行存储过程

我们正在寻找将上述代码（在类文件中）删除到某种形式的配置文件的方法

1. 我们正在寻找检索（读取、解析等）和保存（写入、修改等）速度极快的文件存储格式

2. 我们可以在它上面实现一个安全层

3. 无需大惊小怪和对现有代码进行重大更改即可实现这一目标。

我很高兴能够使用 DAC Fx 和声明式数据库开发。对我来说，主要障碍是如何处理跨多个不同版本模式的复杂数据迁移。在旧世界中，我们可以简单地按顺序运行我们所有的升级脚本，这可以保证架构在数据迁移时处于正确的状态。当升级路径是动态的时，这是如何工作的？

例如，假设现有实例上有我的架构 (DACPAC1-4) 的多个版本：

• DACPAC1：tableA 存在并且有有价值的客户数据
• DACPAC2：不推荐使用 tableA 并由 tableB 和规范化 tableC 替换；添加新表D
  • 部署后脚本：将数据从 tableA 移动到新的 tableB 和 tableC；删除表A
• DACPAC3：tableC 有一个新的可为空的 columnX
  • 部署后脚本：基于 tableD 填充可为空的列
• DACPAC4：tableC.columnX 不可为空

如果我需要能够支持将 DACPAC1-3 服务器升级到最新的 DACPAC4，我现在必须以足够聪明的方式编写我的部署前和部署后脚本，以检测目标上当前是哪个 DACPAC 并正确处理数据迁移步骤顺序。此外，我不能简单地重复使用我最初编写的幼稚的部署后脚本，因为它们依赖于模式的中间版本。

提前感谢您的任何建议！

在部署到 SQL Azure 数据库时，我有一个关于数据层应用程序 (DACPAC) 升级的问题。当我们通过向导 UI 手动升级 DACPAC 时，有一个步骤是我们查看数据丢失警告报告并能够将操作报告保存到 HTML 文件（请参阅此处的“查看升级计划页面”）。操作列显示将运行以执行升级的操作，例如 Transact-SQL 语句。如果相关操作可能会删除数据，则数据丢失列将包含警告。

现在，我正在使用 Powershell 自动化数据库升级过程，到目前为止效果很好。不幸的是，我找不到生成相同数据丢失警告报告的方法。

我的 Powershell 升级脚本的摘录如下：

生成的DatabaseChanges.txt输出文件GetDatabaseChanges()并没有提供真正的信息，所以我们想知道是否有一种方法可以获得与手动完成升级向导时获得的报告文件相同的报告文件。在解决数据迁移问题时，此报告对部署团队有很大帮助，我们希望在部署到实时生产数据库时能够手动检查它。

我们搜索了 MSDN 文档，但没有任何运气。有谁知道 Powershell 部署是否支持此功能？是否有计划在不久的将来支持此功能？

提前感谢您的帮助。

I have a data-centered application with SQL Server. The environments in which it´ll be deployed are not under our control and there´s no DBA in there (they are all small businesses) so we need the process of distribution of each application/database update to be as automatic as possible.

Besides of the normal changes between versions of an application (kind of unpredictable sometimes), we already know that we´ll need to distribute some new seed data with each version. Sometimes this seed data will be related to other data in our system. For instance: maybe we´ll need to insert 2 new rows of some master data during the v2-v3 update process, and some other 5 rows during the v5-v6 update process.

EF

We have checked Entity Framework Db Migrations (available for existing databases with no Code-First since 4.3.1 release), which represents the traditional sequential scripts in a more automatic and controlled way (like Fluent Migrations).

SSDT

On the other hand, with a different philosophy, we have checked SSDT and its dacpacs, snapshots and pre- and post-deployment scripts.

The questions are:

1. Which of these technologies / philosophies is more appropriate for the case described?

2. Any other technology / philosophy that could be used?

3. Any other advice?

Thanks in advance.

是否有适用于 VS 2010 的 SQL Server 2012 数据层应用程序模板？我使用的模板版本只允许 SQL Server 2008R2。

如果我在 SQL Server 2012 中打开管理控制台并提取一个 DAC 包，则可以正常工作并创建包。但是，VS 不允许我导入包，它给出以下错误：“您指定的文件不是有效的数据层应用程序文件。请指定一个有效的文件。”

DacUpgradeOptions.IgnoreDataLoss在自动数据层应用程序 (DACPAC) 升级中设置属性的最佳做法是什么？

根据 MSDN 文档（链接），如果IgnoreDataLoss为True，即使某些操作导致数据丢失，升级也会继续进行。如果为False，这些操作将终止升级。例如，如果当前数据库中的表不存在于新 DAC 的架构中，则如果指定 True，则该表将被删除。默认值为True。

但是，在持续交付的环境中，每次数据库更改都会自动部署到管道（CI -> Test -> UI-Test）并最终部署到生产环境中，似乎将安全措施设置IgnoreDataLoss为False，因为我们不希望生产数据库上发生数据丢失/漂移。如果IgnoreDataLoss为False并且开发人员提交了导致数据丢失的数据库更改，则 CI/Test 构建将失败，从而使我们能够在此更改到达生产之前捕获它。

但是这种方法存在一个问题，因为有时数据丢失是故意的。例如，我们可能需要删除不再使用的特定表。如果IgnoreDataLoss是False，这将导致构建失败并且永远不会应用 DACPAC 更改，因为检测到潜在的数据丢失（即使这种丢失是故意的）。在这种情况下，我们希望IgnoreDataLoss是True。

只是想知道什么是最佳实践，尤其是在我们持续自动部署的环境中。任何建议将不胜感激。谢谢！

我在跟踪我的 DAC 版本时遇到了一些问题。我无法看到当前版本的数据库。幸运的是，我找到了这篇文章： 如何找到 SQL Server 数据层应用程序的当前版本？

第二个答案成功了，现在我可以使用 SQL 语句查看当前版本：

现在我可以看到当前版本和新 dacpac 的版本，但方式非常难看。我还有一些问题/不确定性。

1. 出于某种原因，我没有在 SSMS 中看到管理下的数据层应用程序。我只是为 SQL 2008 R2 建立了关于这个的讨论，所以我不确定是在 SQL 2012 中放弃了还是我做错了什么。

2. 在 SSMS 中升级数据层应用程序时，我只能在升级向导中达到摘要步骤时看到 dacpac 版本。当我在选择包步骤中选择新的 dacpac 时，我希望在下面的向导中看到所选 dacpac 的版本和描述（如许多教程中所述），但没有出现任何内容。根据我在那些教程中找到的图像，即使在摘要步骤中，我也看不到当前 DAC 数据库的版本，而 2008 R2 就是这种情况。

3. 有没有比这更好的处理版本比较的方法，比如在同一个地方显示当前版本和新版本？如果您尝试使用具有相同或更低版本号的 dacpac 进行升级，有没有办法显示警告？

谢谢

马尔科