在我工作的地方，我们有一个用于数据存储和访问的 IBM Power System。它当前运行的是 iOS 6.1。我们在 IIS 服务器上有一个网站，可以从该服务器中提取数据，并且有几个不同的 Web 应用程序可以执行不同的功能。所有这些都具有某种搜索功能。其中两个站点存在区分大小写的问题。
这是它变得有点毛茸茸的地方。当我们在 IBM 系统上从 v5r4 升级到 v6r1 时，这个问题才开始发生。不过，并非所有站点都发生这种情况（总共有 8 个，其中 2 个有问题）。这很奇怪，因为它们都使用相同的 IO 程序。该网站由另一方开发，能够远程测试我们的数据库。他们运行的是 v7r1，并且在将站点与我们的数据库一起使用时没有任何问题。该网站通过 ODBC 访问数据，我尝试重新配置 DSN。一位支持人员甚至让我用 .reg 文件注册他们准确的 ODBC 配置，但仍然没有。他们和我都没有想法，所以现在，我们求助于帮助链接。我碰巧在使用同一台服务器进行查询的不同网站上工作，并且该站点中的 ODBC 连接具有相同的行为...名称和任何其他搜索字段似乎都区分大小写。我知道，因为我突然对我的网站无法正常工作感到惊讶，所以我的网站在 v6r1 升级之前不区分大小写。我们还使用第 3 方应用程序来运行 SQL 查询，并且在同一个 DSN 上，此应用程序中的查询不区分大小写。所以正如你所看到的，我找不到任何相关性。有谁知道 IBM DSN 的问题或 IBM 服务器/文件系统的区分大小写可能会导致某些查询出现这种情况？并且在同一 DSN 上，此应用程序中的查询不区分大小写。所以正如你所看到的，我找不到任何相关性。有谁知道 IBM DSN 的问题或 IBM 服务器/文件系统的区分大小写可能会导致某些查询出现这种情况？并且在同一 DSN 上，此应用程序中的查询不区分大小写。所以正如你所看到的，我找不到任何相关性。有谁知道 IBM DSN 的问题或 IBM 服务器/文件系统的区分大小写可能会导致某些查询出现这种情况？
如果怀疑是 ODBC 驱动程序，请检查 DSN。选择语言选项卡，然后选择排序类型“基于语言 ID 排序”。然后选择您的语言 ID。默认设置是“基于 *HEX 值排序”。
如果怀疑是 IBM i 服务器，让管理员检查服务器作业的 SRTSEQ 属性 - QZDASOINIT，可能 - 将其设置为 *LANGIDSHR。默认为 *HEX。显然，这将影响对 IBM 服务器的所有 ODBC 访问，而不仅仅是您的访问。但如果升级前是这样的话，或许最好还是放回去。
如果查询明确处理单壳，它可能会更透明。所以不是...WHERE CUSTNAME LIKE 'JONES%'...而是...WHERE UPPER(CUSTNAME) LIKE 'JONES%'...