标签: sql-server-data-project

我一直在使用SQL Server项目来管理数据库的结构.

首先我创建了项目,然后导入了一个数据库.

然后,当我需要进行模式更改时,请更改字段名称,我在SQL Server项目中执行,然后使用模式比较选项将其发布到实际数据库.

我想更进一步,以保存数据库所需的基本数据.例如,一个OrderType包含2条记录"PHONE","WEB" 的表格

数据库的所有新实例都需要此数据.有没有办法将这些保留在SQL Server项目中,以便它们不会丢失？

现在看来,唯一的方法是保留master数据库的实际副本及其中的元数据,然后使用数据比较.但是,如果数据可以与模式同时发布,那么结果数据库就完成了,那就太棒了.

我正在使用SQL Server数据层应用程序来控制数据库的源代码.我在Visual Studio中创建了SQL Server数据库项目,现在正在通过PowerShell自动部署DACPAC.在使用DacFx服务部署方法测试部署选项时,我一直在使用部署选项,特别是BlockWhenDriftDetected.

现在,根据我的理解,在将所述数据库部署并注册为数据层应用程序之后,在SQL Server中向外部部署的数据库添加某种类型的SQL Server对象(表,函数,sproc等)时会发生数据库偏移.说服务器.正如我已经测试过的那样,这种漂移检测似乎有点不对劲.

当我第一次部署/注册DACPAC时,当然一切都很好,并且没有漂移.但是,如果我唯一更改的是VS中我的数据库项目属性中的版本号,重建项目,然后尝试使用DacFx重新部署DACPAC文件,它会检测数据库漂移.

要部署我的DACPAC,我使用以下powershell代码:

Add-Type -Path "C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin\Microsoft.SqlServer.Dac.dll"

$dacservices = New-Object Microsoft.SqlServer.Dac.DacServices "server=(localdb)\v11.0;trusted_connection=true;"
$dacpac = [Microsoft.SqlServer.Dac.DacPackage]::Load("C:/Projects/Sample/DacProject/bin/Debug/MyDatabase.dacpac")

$deployOptions = New-Object Microsoft.SqlServer.Dac.DacDeployOptions
$deployOptions.RegisterDataTierApplication = $true;
$deployOptions.BlockWhenDriftDetected = $true;

$dacservices.Deploy($dacpac, "MyDatabase", $true, $deployOptions)

更新版本号并重建后再次运行上面的代码,我将得到漂移检测错误:

Exception calling "Deploy" with "4" argument(s): "Could not deploy package.
Error SQL0: Database has drifted from its registered data-tier application.

另外,当我检查数据库漂移时,让事情更加混乱......

Write-Host $dacservices.GenerateDriftReport("MyDatabase")

我得到一份空报告,意思是一切都应该没问题:

<DriftReport xmlns="http://schemas.microsoft.com/sqlserver/dac/DriftReport/2012/02">
  <Additions />
  <Removals />
  <Modifications />
</DriftReport>

这是一个错误还是我错过了什么？我很想忽略整个漂移检测并强制严格访问生产数据库,试图在事后限制变化.任何帮助将不胜感激.

谢谢.

我有一个SQL Server数据库,其中包含默认架构和自定义架构.例如,两个表可能是database.dbo.table1和database.customschema.table2.

我想在源代码管理下保留"customschema"数据库对象,并且我已成功将这些对象加载到Visual Studio 2015 SQL Server数据库项目中.

但是,当我使用工具 - > SQL Server - >新架构比较...实用程序时,它会返回数据库中所有架构的差异.所以它会显示所有"dbo"表在数据库项目中不同/删除,即使我不"关心"那些表,因为我不打算将它们保存在源代码管理下的db项目中.

有没有办法限制结果只显示我的数据库项目和"customschema"对象的实际数据库之间的差异,并忽略与dbo对象的任何差异？

如何直接从 Visual Studio SQL Server 数据库项目构建 EF Core？

优选以下解决方案：

scaffold-dbcontext -connection "provider=ssdtproject, name=myprojectname.sqlproj"
scaffold-dbcontext -ddl "ssdtprojectoutput.sql"
scaffold-dbcontext -ssdtschema "ssdtproject.dacpac"
maintained-third-party-tool myprojectname.sqlproj -EfModelGenerationParameters

这就是整个问题。以下是我更详细的情况，以便您能够提供替代解决方案：

尽管 MS 承认 EF Core 尚未做好生产准备，但距 EF 6 进展停止已有 3-4 年了，EF Core 是唯一具有 NETCore 兼容性的 LINQ 代码类似路径。标题为“所以您将使用 EF Core ”的传奇由此开始。

这部分内容固执己见，但对我来说（基于 25 年以上的企业软件设计和开发经验）Code-First 绝对是行不通的。对于小型的一周应用程序概念来说，这很好，但我认为没有合理的模式/流程/实践来集成约束、视图等。如果没有设计视图，真正的业务应用程序最终会导致开发人员在 LINQ 表达式中重复逻辑基础知识到处都是，用静态字段乱扔代码来支持 LINQ-to-SQL 查询，使用 LinqKit 混淆微组合模式，等等。如果没有约束，我们最终会得到十倍于处理运行时错误的防御性代码要求，快速发展的单元集成测试和演示失败成为常态。要么我们的面向对象专家需要成为 SQL 专家，要么相反，我们大大增加了寻找和适当补偿工程师的难度。所有这些问题都是我在四年前与 Rowan Miller（他最近离开 EF 团队，这对于短期解决方案来说不是一个好兆头）的一次详细对话中指出的。

模型优先（.edmx早期 EF 版本中的视觉设计器）显然是不可能的，因为 MS 对此的解决方案是声称代码优先实际上就是模型优先，并且不再理会它。因此，为清楚起见，我们将其称为“合同优先”的真正中立的方法在 EF Core 中并不存在。

所以，这个咆哮（抱歉，沮丧）让我想到了数据库优先，因此Scaffold-DbContext. 我们的数据库架构目前是一个版本控制的 Visual Studio SQL Server 数据库项目。除了一些已知的问题 …