小编And*_*ans的帖子

我安装了 SQL Server 2012 本地数据库，并通过 (localdb)\v11.0 连接到它。

尝试恢复备份文件时，我得到：

标题：Microsoft SQL Server 管理工作室

属性 MasterDBPath 不可用于信息“Microsoft.SqlServer.Management.Smo.Information”。此对象可能不存在此属性，或者可能由于访问权限不足而无法检索。(Microsoft.SqlServer.Smo)

如需帮助，请单击：http : //go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=11.0.2100.60+((SQL11_RTM).120210-1846+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates .PropertyCannotBeRetrievedExceptionText&EvtID=MasterDBPath&LinkId=20476

我曾尝试在以下位置设置 MasterDBPath 字符串值：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\CurrentVersion`

但这没有帮助。

有人有什么想法吗？

就像之前在这里发布的关于“开发人员应该能够查询生产数据库吗？ ”的问题的脉络一样，我想了解您对另一个特别烦人的话题的看法！

许多公司阻止开发人员在开发机器上安装 SQL Server Express 等，而是提倡使用集中式开发 SQL Server。

具体来说，这样做是为了确保：

• 开发服务器和生产之间的补丁级别一致性
  
• 能够证明和验证上述任何补丁
  
• 数据安全; 只有开发服务器上的数据才能用于开发
  
• 可恢复性；数据可恢复且仍在备份
  
• 转移到生产时可能导致问题的排序规则差异

对我来说，所有这些论点都特别无效，也许修补程序除外。但是如果本地机器上的数据库纯粹用于开发活动，而不是测试，那么当应用程序通过测试/UAT 等进入生产时，补丁将被证明。

排序规则似乎不是一个有效的理由，好像这是数据库的一个问题，它应该在创建时设置。据我所知，只有 SharePoint 和 SCCM 有这方面的问题；)

现在，假设它仅用于开发，并且数据库不会“移动”到生产中，唯一的移动是：

• 创建用于部署到生产的数据库的脚本
• 来自“生产”第三方系统的备份在适合验证和开发的情况下被恢复和截断

任何人都可以看到任何问题吗？我错过了什么吗？

我想最大的问题之一是本地数据库实例过时的能力，但那是软件管理问题，而不是 DBA 的 IMO。