在我们当前的 prod 环境中，当 ETL 启动时，它首先检查操作系统级别的环境变量，该变量告诉它“配置”数据库和表的位置，以便它获取运行所需的值/参数。
在我们的测试环境中，虽然我们将在同一个物理机器上进行测试和 QA，但使用不同的 SQL Server 实例。我得到的反馈是，因为它们在同一个物理盒子上，这意味着一个 env 变量，所以我们必须根据 ETL 是在测试还是 QA 中运行来更改 env 变量。这不太理想。
我明白不想将任何东西硬编码到包中，但必须有一种方法可以在同一个物理盒子上的多个环境中完成这样的事情。我无法证明为每个环境拆分到单独的物理硬件上是合理的。
别人做了什么。想法？什么有效，什么无效？
在此之前我会说我完全不相信这不是供应商在他们的应用程序服务器上做错了什么。只是在寻找新的想法
实例 X 是 SQL Server 2008 R2 的命名实例。它包含大量数据库并接收来自大量应用程序服务器的连接。浏览器服务正在运行，所有连接都是通过服务器\实例名称进行的。
前几天将数据库从旧的 2K5 实例转移到它，供应商声称他无法连接到数据库。他说他只是在他的连接字符串中输入了 Server\instance 名称，但他的连接失败了。目前他不能/没有向我提供任何真正的错误信息。
每当他尝试时，我们都看不到成功或失败的证据。截至目前，没有证据表明他甚至击中了命名实例。不过，他可以测试 2008 R2 默认实例。因此，由于命名实例似乎有所不同，我认为这与端口号有关。我们没有明确地尝试过端口号，因为我们需要它只使用名称并且供应商发誓应该这样做。但是，我们可以通过 SQLCMD 和设置基本 ODBC 来连接他的凭据。
应用程序服务器是 2003R2，在我看来，它很糟糕，但更换它不是一种选择。DBNETLIB.DLL 版本为 2000.86.3959.0，本机客户端版本为 2005.90.3042。您将不得不回溯很长一段时间才能无法命中命名实例。
我错过了任何过于明显的东西吗？从客户服务的角度来看，宁愿不只是说“适用于其他所有人！”。
编辑9:44PM Central - 应该在原始帖子中注意到防火墙未在应用程序服务器上打开，我们不会过滤/阻止网络内部的任何内容。