到目前为止，我已经了解了有关 Microsoft SQL Server Express 的以下事实，包括版本 2012 和更早的版本，如 2008R2 和 2008，并且在很大程度上一直追溯到 SQL Server 2005。我正在“上配置 SQL SERVER”工作组服务器”机器，也就是说，它是一个专用服务器盒，运行 Windows Server 操作系统，但它使用的是 WORKGROUP，并且只运行 Microsoft SQL Express。
请注意以下背景事实：
配置 SQL Express 实例是开箱即用的，无需配置 TCP/IP。
打开 TCP/IP 选项（将 SQL Server 配置器的 TCP/IP 协议列表项从否更改为是）是不够的，有时您还必须选择重新配置静态和动态端口选项。例如，对于单个实例，您可以将静态端口设置为 1433，并将动态端口设置为空白（如果存在，则删除 0）。这是重复进行的，在一些具有 IPV4 和 IPV6 以及一个物理和多个虚拟以太网适配器的 Windows 机器上，这可能是 4、8 甚至 16 个地方，您必须在这些地方设置静态和动态端口。
或者，您可以配置 SQL 浏览器并启用它，这通常有助于解决复杂的 TCP/IP 连接问题，但通常不会。
在域上，我很少遇到奇怪的问题，所以这个问题不是针对基于域的 SQL Server 部署，而是针对工作组部署。不，我没有选择在工作组上运行我的办公室，但我的许多客户/客户确实选择了这个选项，而且我应该在工作组上支持 SQL Express。
以上所有内容都是背景知识，目的是让下一部分清楚我的实际问题：
没有域的小型办公网络中的许多 WORKGROUP 客户端系统似乎有通过 TCP/IP 连接的奇怪问题，甚至只是自动协商与 SQL Server 数据库的连接，我无法在我自己的任何办公室或家庭网络，其中 SQL 连接将不起作用，即使 SQL 浏览器正在运行，SQL 静态和动态端口选项已配置，防火墙已关闭，ping 工作正常，但使用 SQL 客户端的 TCP/IP 连接在 Windows 7 MDAC 组件中提供的，是不可能的。请注意，它不像安装 SQL Native Client v10 或 SQL native Client V11 那样简单。这些客户端的唯一解决方法是使用 CLICONFG 禁用 TCP/IP。EXE plus 通过在服务器名称前加上“NP:”来禁用 SQL 数据库连接字符串中的自动协商。这个客户的工作组 LAN 从根本上是不兼容的，即使是在 TCP 端口 1433 上侦听的静态单个 SQL Server 实例，也没有 SQL 浏览器或动态端口。
这些相同的客户端通常有 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+路由器+NAT 盒中的 DHCP 服务器获取动态 IP 地址，例如Linksys WRT64G。我给出了一个特定的模型，这样我就可以清楚地知道这些用户没有任何你会认为是“IT 风格”的局域网。这些人经营的是小公司，没有 IT 预算，没有 IT 人员，也没有 Windows 网络或域基础设施。他们有一个 SQL Server 实例在 Windows Server 驱动的计算机上运行，从软件供应商（我）购买，以运行软件应用程序，并且不愿意切换到使用域。
以上所有都是真实的，我很困惑为什么 SQL over TCP 启用了 IPV6 和 IPV4（开箱即用的 Windows 7 32 位网络配置）会如此难以工作。到目前为止，我得到的唯一部分答案是，在某些情况下，工作组名称的差异似乎是造成某些问题的原因。（机器 A 没有问题，运行的是 Windows 7，工作组名称设置为 WORKGROUP，机器 B 有问题，运行的是 Windows 7，工作组名称设置为 MYCOMPANY。）
请注意，一些人可能会遇到的一个相关的令人困惑的问题是 SQL 身份验证和 Windows（集成）身份验证之间的选择。在工作组中配置连接时，我们总是使用 SQL 身份验证，由于缺少域，这似乎是完全必要的，这不是我要问的。我只询问 TCP/IP 与命名管道，以及我无法配置在工作组上工作的 TCP/IP 连接的原因，但是，我可以在大多数 WAN、VPN 甚至互联网上轻松配置它们.
为什么 WINDOWS WORKGROUP LAN 是 TCP/IP 连接到 SQL Server Express 的特例？
您所说的 DNS 和 TCP 之间没有“信任”。在 DNS 促进基于名称的 TCP 主机连接方面，DNS 和 TCP 之间存在关系，但肯定没有任何“信任”。为了让一台主机通过名称连接到另一台主机，该名称必须是可解析的。这称为名称解析。它通常是通过 DNS 实现的，但在您描述的工作组场景中，没有中央 DNS 服务器来处理客户端的名称解析。
在您描述的场景中，不存在提供名称解析的通用 DNS 服务器，客户端将求助于 LLMNR 或广播，具体取决于客户端。这两种方法都不能保证每个主机都能够解析每个其他主机的名称。
这不是魔法，也不是神秘。如果你想定期可靠地将主机名解析为 ip 地址，那么你需要实现一个内部 DNS 服务器并相应地配置客户端。对于工作组客户端，这意味着必须手动配置其 DNS 后缀以匹配您为工作组创建的 DNS 服务器上的 DNS 区域，然后将所有客户端配置为使用该 DNS 服务器进行 DNS。