无法连接到 SQL Server 2017 本地数据库共享实例

此问题通过以下方式解决：

KB5003342-修复：SQL Server Express LocalDB 无法启动或连接到 SQL Server Express LocalDB 2019 或 2017 的共享实例

假设您在 Microsoft SQL Server 2019 或 2017 中使用 SqlLocalDB 功能。在这种情况下，您无法正确启动或连接到 SqlLocalDB 的共享实例。

此问题已在 SQL Server 的以下累积更新中得到修复：

• SQL Server 2019 的累积更新 11

• SQL Server 2017 的累积更新 24

演示：

似乎是 LocalDb v2017 及更高版本中的错误。我测试了所有可用的版本，从 v2012 SP4 开始。在 v2016 SP2 之前（包括 v2016 SP2），友好共享名称"(localdb)\.\SHAREDNAME"在连接请求中被接受。使用 v2017 或更高版本时，请求始终会导致“未找到实例”错误。

我还观察到查询所有已安装的 LocalDb 版本sqllocaldb.exe v会导致出现 v2016 及更高版本的错误消息：

Windows API 调用“RegGetValueW”返回错误代码：0。

不确定此行为是否可能与原始问题有关。

应用问题中链接的注册表修复解决了版本查询。

经过一番挖掘，我想我可能已经找到了连接失败的原因。在本地计算机上安装最高 v2016的 SQLLocalDb 时，共享功能的工作方式如下：

在注册表中，会在 中创建一个新键Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\{SharedName}。此键包含一个字符串 value InstanceName，它存储管道名称，如以下屏幕截图所示：

当相应的实例启动时，它总是选择这个管道名称。该名称保持不变，即当实例重新启动时，管道名称被重用。

安装 LocalDb v2017 或更高版本时会破坏此逻辑：当启动具有共享名称的实例时，将忽略注册表中的管道名称。相反，通过查询实例时会出现完全不同的管道名称sqllocaldb i {instance}。

这可能也是无法建立连接的原因，因为管道名称不匹配。编辑注册表值以匹配实际管道名称可以解决问题，但仅在重新启动实例之前。

正如 Aurora 所建议的那样，这是 LocalDB >= 2017 中的一个错误，微软似乎并不关心它。原因可能是因为 LocalDb 不应该在生产环境中使用。建议的解决方法很好，但需要手动完成。

要在您的软件中解决此问题，您可以实施以下解决方法：

1. 创建一个每 30 秒左右运行一次的辅助进程/后台任务。
2. 检查实例是否已启动（使用 SqlLocalDbApi 类或sqllocaldb i {your_shared_instance_name}在单独的进程中运行并获取结果）。此外，此时记录命名管道（格式：np:\\.\pipe\LOCALDB#AC471EDC\tsql\query- 提取管道 id 值使用此正则表达式：#(.*?)\\-> 如果匹配使用match.Groups[1].Value）
3. 通过检查以下注册表来验证实例管道名称：SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{your_shared_instance_name}
4. 如果第 2 点记录的管道名称与注册表值不同，请更新注册表项InstanceName

（C# 示例）

获取密钥：

using var myKey = Registry.LocalMachine.OpenSubKey($"SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\\{instanceName}", true);

如果它与管道 ID 不同：

myKey.SetValue("InstanceName", $"LOCALDB#{pipeId}", RegistryValueKind.String);

结论

现在一切都应该工作了。每 30 秒左右检查一次，以确保在数据库进程失败/系统重新启动/等情况下恢复正常。抱歉，但这似乎是 2017 年升级后保持 LocalDb 存活的唯一解决方案。另一种解决方案是迁移到 SQL Express 服务器。

这只是代码的一个示例，但希望您能理解。如果没有，请发表评论，我会尽力帮助您。我为此挣扎了一会儿，但它最终以 LocalDb 2014/2016 的形式运行，没有任何问题。