到目前为止，我已经了解了有关Microsoft SQL Server Express（包括版本2012）以及早期版本（如2008R2和2008）以及大部分所有返回到SQL Server 2005的事实。我正在configurationSQL Server“工作组服务器“机器，也就是说，它是一个运行Windows Server操作系统的专用服务器机箱，但是它使用的是一个WORKGROUP，它只能运行Microsoft SQL Express。
请注意以下背景资料：
configuration一个SQL Express实例在没有configurationTCP / IP的情况下出现。
打开TCP / IP选项（将TCP / IP的SQL Serverconfiguration程序协议列表项目从No更改为Yes）是不够的，有时您还必须select重新configurationStatic和Dynamic端口选项。 例如，对于单个实例，可以将静态端口设置为1433，将dynamic端口设置为空白（如果存在，则删除0）。 这是重复的，在一些具有IPV4和IPV6的Windows机器上，以及一个物理的和多个虚拟的以太网适配器上，这可能是4,8甚至16个必须设置静态和dynamic端口的地方。
或者，您可以configurationSQL浏览器并启用它，这通常有助于解决复杂的TCP / IP连接问题，但通常不会。
在域中，我很less有奇怪的问题，所以这个问题不是基于域的SQL服务器部署，而是工作组部署。 不，我没有select在工作组上运行我的办公室，但是我的许多客户/客户都select了这个选项，我应该在工作组上支持SQL Express。
以上所有内容都是背景知识，下面的部分就是我的实际问题：
在没有域的小型办公networking中，许多WORKGROUP客户端系统似乎都有通过TCP / IP连接的奇怪问题，甚至只是自动协商到SQL Server数据库的连接，我无法在自己的办公室或家庭networking，SQL连接将无法运行，即使SQL浏览器正在运行，SQL静态和dynamic端口选项已configuration，防火墙已被closures，并且ping工作正常，但使用SQL客户端的TCP / IP连接在Windows 7 MDAC组件中运行，是不可能的。 请注意，它不像安装SQL Native Client v10或SQL本机Client V11那么简单。 这些客户端的唯一解决方法是使用CLICONFG.EXE禁用TCP / IP，并通过在服务器名称前添加“NP：”来禁用SQL数据库连接string中的自动协商。 有关此客户端的工作组局域网的基本上是不兼容的，即使是在侦听TCP端口1433的静态单个SQL Server实例，也没有SQL浏览器或dynamic端口。
这些相同的客户端通常有12台机器，12台机器中的6台不能通过自动（不强制命名pipe道）连接string进行连接，只能在连接types被强制命名为pipe道时才能连接。
强制命名pipe道的典型连接string可能会在主机和实例的前面放置“NP：”，如下所示：“NP：HOSTNAME \ SQLEXPRESS”，另外我们会去该客户机的CLICONFG.EXE并禁用TCP / IP。 这两个步骤在一些工作组情况下似乎是必需的
还有一个问题是，为什么在我的客户站点中有一半的Windows 7客户端系统（平均每12个中有6个）没有能力通过他们的工作组局域网上的TCP / IP进行SQL通信。
一些资格和一般事实：
很多无法连接的系统都是32位Windows 7客户端，没有安装额外的SQL客户端连接组件，而不是Windows内置的任何MDACfunction。
我尝试连接的应用程序正在使用ADO，并且在Windows 7中提供的底层MDAC组件上运行良好。
为特定的SQL 2012或2008R2服务器（SQL本机客户端11，SQL本机客户端10）安装“本机客户端”组件对这些问题没有任何影响，不能解决这些问题，或者使任何更好或更糟糕的事情发生。
我怀疑一些涉及IPV4，IPV6，DNS以及缺乏“信任问题”的基本问题，这些问题导致TCP / IP + DNS连接的基本部分“半损坏”，但是我还没有发现关于此主题的任何准确的SQL Server文档。
这些客户站点没有Windows Active Directory域，也没有基于Windows的DHCP服务，并且通常通过内置到低端商用或住宅级WiFi + DSL +路由器+ NAT盒的DHCP服务器获得其dynamicIP地址，例如一个Linksys WRT64G。 我正在给出一个具体的模型，所以我可以清楚地知道，这些用户没有什么可以认定为“IT风格”的局域网。 这些人正在运营小公司，没有IT预算，没有IT人员，也没有Windowsnetworking或域的基础设施。 他们有一个SQL Server实例运行在Windows服务器供电的计算机上，从软件供应商（我）购买，运行一个软件应用程序，并且不愿意切换到使用域。
以上所有内容都是真实的，我很困惑为什么启用IPV6和IPV4的TCP over TCP（缺货的Windows 7 32位networkingconfiguration）将很难实现。 到目前为止，我唯一的部分答案是，在某些情况下，工作组名称上的差异可能是造成一些麻烦的原因。 （机器A没有问题，运行的是Windows 7，工作组名称设置为WORKGROUP，机器B有问题，并且正在Windows 7上运行，并且工作组名称设置为MYCOMPANY。）
请注意，有些人可能会遇到的相关混淆问题是SQL身份validation和Windows（集成）身份validation之间的select。 在工作组中configuration连接时，我们总是使用SQL身份validation，由于缺less域，这似乎是完全必要的，而不是我所问的。 我只是询问TCP / IP与命名pipe道的关系，以及为什么我无法configuration在工作组上工作的TCP / IP连接的原因，然而，我可以在大多数WAN，VPN甚至跨互联网。
为什么WINDOWS WORKGROUP LAN是TCP / IP连接到SQL Server Express的特例？
我怀疑一些涉及IPV4，IPV6，DNS以及缺乏“信任问题”的基本问题，这些问题导致TCP / IP + DNS连接的基本部分“半损坏”，但是我还没有发现关于此主题的任何准确的SQL Server文档。
你所说的DNS和TCP之间没有“信任”。 DNS和TCP之间有一种关系，就是为了方便基于名字的连接到TCP主机，但是肯定没有任何“信任”。 为了让一个主机通过名称必须可以解决的名称连接到另一个主机。 这就是所谓的名称parsing。 通常情况下，它是通过DNS实现的，但是在工作组场景中，您描述的是没有中央DNS服务器来处理客户端的名称parsing。
在您描述的场景中，如果不存在通用的DNS服务器来提供名称parsing，则客户端将根据客户端采取LLMNR或广播。 这两种方法都不能保证每个主机都能够parsing其他主机的名称。
这不是魔术，这不是一个谜。 如果要定期和可靠地将主机名parsing为IP地址，则需要实施内部DNS服务器并相应地configuration客户端。 对于工作组客户端，这意味着必须手动configuration其DNS后缀以匹配您为工作组创build的DNS服务器上的DNS区域，然后configuration所有客户端以使用该DNS服务器进行DNS。