到目前为止，我了解到了有关 Microsoft SQL Server Express 的以下事实，包括版本 2012 和早期版本，如 2008R2 和 2008，并且大部分可以追溯到 SQL Server 2005。我正在“工作组服务器”机器上配置 SQL SERVER，也就是说，它是一个专用的服务器箱，运行 Windows Server 操作系统，但它使用工作组，并且只运行 Microsoft SQL Express。
请注意以下背景事实：
配置 SQL Express 实例无需配置 TCP/IP。
仅打开 TCP/IP 选项（将 SQL Server Configurator 的 TCP/IP 协议列表项从“否”更改为“是”）是不够的，有时您还必须选择重新配置静态和动态端口选项。例如，对于单个实例，您可以将静态端口设置为 1433，将动态端口设置为空白（如果存在则删除 0）。此操作会重复执行，在某些具有 IPV4 和 IPV6 以及一个物理和多个虚拟以太网适配器的 Windows 计算机上，您可能需要设置 4、8 甚至 16 个静态和动态端口。
或者，您可以配置 SQL 浏览器并启用它，这通常有助于解决复杂的 TCP/IP 连接问题，但通常却无济于事。
在域名上，我很少有奇怪的问题，所以这个问题不是针对基于域的 SQL 服务器部署，而是针对工作组部署。不，我没有选择在工作组上运行我的办公室，但我的许多客户/客户确实选择了此选项，我应该在工作组上支持 SQL Express。
以上所有内容均为背景信息，旨在阐明我的实际问题下一部分：
小型办公网络中没有域的许多工作组客户端系统似乎在通过 TCP/IP 连接时出现奇怪的问题，甚至在自动协商与 SQL Server 数据库的连接时也出现问题，而我无法在自己的办公或家庭网络中复制这种情况，在这些网络中，SQL 连接无法正常工作，即使 SQL 浏览器正在运行，并且已配置 SQL 静态和动态端口选项，防火墙已关闭，ping 工作正常，但使用 Windows 7 MDAC 组件中附带的 SQL 客户端进行 TCP/IP 连接是不可能的。请注意，它并不像安装 SQL Native Client v10 或 SQL Native Client V11 那么简单。这些客户端的唯一解决方法是使用 CLICONFG.EXE 禁用 TCP/IP，并通过在服务器名称前加上“NP:”来禁用 SQL 数据库连接字符串中的自动协商。即使有一个静态的 SQL Server 实例在 TCP 端口 1433 上侦听，并且没有 SQL 浏览器或动态端口，此客户端的工作组 LAN 也存在根本上的不兼容问题。
这些相同的客户端通常有 12 台机器，而 12 台机器中有 6 台无法通过自动（不强制命名管道）连接字符串进行连接，并且只能在连接类型强制为命名管道时才能连接。
强制使用命名管道的典型连接字符串可能会将“NP:”放在主机和实例前面，如下所示：“NP:HOSTNAME\SQLEXPRESS”，另外，我们会转到该客户端的 CLICONFG.EXE 并禁用 TCP/IP。在某些工作组情况下，这两个步骤似乎都是必要的。
问题再次是，为什么我的某些客户站点上一半的 Windows 7 客户端系统（平均 12 个中的 6 个）无法通过其工作组局域网上的 TCP/IP 进行 SQL 通信。
一些资格和一般事实：
许多无法连接的系统都是 32 位 Windows 7 客户端，除了 Windows 内置的 MDAC 功能外，没有安装其他 SQL 客户端连接组件。
我尝试连接的应用程序使用 ADO，并且在 Windows 7 附带的底层 MDAC 组件上运行良好。
为特定的 SQL 2012 或 2008R2 服务器（SQL Native Client 11、SQL Native Client 10）安装“本机客户端”组件对这些问题没有影响，不会修复这些问题，也不会使任何问题变得更好或更糟。
我怀疑一些涉及 IPV4、IPV6、DNS 和缺乏“信任问题”的潜在问题导致 TCP/IP + DNS 连接的基本部分“半中断”，但我没有找到有关此主题的任何准确的 SQL Server 文档。
这些客户站点没有 Windows Active Directory 域，也没有基于 Windows 的 DHCP 服务，并且通常通过内置于低端商业或住宅级 WiFi+DSL+Router+NAT 盒（例如 Linksys WRT64G）中的 DHCP 服务器获取动态 IP 地址。我给出了一个特定的模型，以便我可以清楚地表明这些用户没有任何您会认为是“IT 风格”的局域网。这些人经营着小公司，没有 IT 预算，没有 IT 人员，也没有 Windows 网络或域基础架构。他们在从软件供应商（我）购买的 Windows Server 驱动的计算机上运行一个 SQL Server 实例来运行软件应用程序，并且不愿意切换到使用域。
以上所有情况都是正确的，但我很困惑为什么启用 IPV6 和 IPV4 的 SQL over TCP（出厂时的 Windows 7 32 位网络配置）会如此难以运行。到目前为止，我唯一能给出的部分答案是，在某些情况下，工作组名称的差异似乎是导致部分问题的原因。（计算机 A 没有问题，运行的是 Windows 7，工作组名称设置为 WORKGROUP，计算机 B 有问题，运行的是 Windows 7，工作组名称设置为 MYCOMPANY。）
请注意，有些人可能会遇到一个相关的令人困惑的问题，即在 SQL 身份验证和 Windows（集成）身份验证之间进行选择。我们在工作组中配置连接时总是使用 SQL 身份验证，由于缺少域，这似乎是完全必要的，而这不是我要问的。我只问 TCP/IP 与命名管道，以及我无法配置通过工作组工作的 TCP/IP 连接的原因，然而，我能在大多数 WAN、VPN 甚至互联网上轻松配置它们。
为什么 WINDOWS WORKGROUP LAN 是与 SQL Server Express 的 TCP/IP 连接的特殊情况？
答案1
我怀疑一些涉及 IPV4、IPV6、DNS 和缺乏“信任问题”的潜在问题导致 TCP/IP + DNS 连接的基本部分“半中断”，但我没有找到有关此主题的任何准确的 SQL Server 文档。
DNS 和 TCP 之间不存在您所说的“信任”。DNS 和 TCP 之间存在某种关系，即 DNS 促进基于名称的 TCP 主机连接，但肯定不存在任何“信任”。为了让一个主机通过名称连接到另一个主机，该名称必须是可解析的。这称为名称解析。通常，它是通过 DNS 实现的，但在您描述的工作组场景中，没有中央 DNS 服务器来处理客户端的名称解析。
在您描述的场景中，没有通用 DNS 服务器提供名称解析，客户端将根据客户端情况采用 LLMNR 或广播。这两种方法都不能保证每台主机都能解析其他每台主机的名称。
这不是魔术，也不是秘密。如果您想要定期可靠地将主机名解析为 IP 地址，则需要实施内部 DNS 服务器并相应地配置客户端。对于工作组客户端，这意味着必须手动配置其 DNS 后缀以匹配您为工作组创建的 DNS 服务器上的 DNS 区域，然后配置所有客户端以使用该 DNS 服务器进行 DNS。