Там, где я работаю, у нас есть IBM Power System, которую мы используем для хранения данных и доступа к ним. В настоящее время он работает под управлением i OS 6.1. У нас есть веб-сайт на сервере IIS, который получает данные с этого сервера и имеет несколько различных веб-приложений, которые выполняют разные функции. Все они имеют какую-то функцию поиска. На двух из этих сайтов есть проблема с чувствительностью к регистру.
Вот где это становится немного волосатым. Эта проблема возникла только тогда, когда мы обновили систему IBM с v5r4 до v6r1. Опять же, это происходит не на всех сайтах (всего их 8, 2 имеют проблемы). Это очень странно, потому что все они используют одни и те же процедуры ввода-вывода. Веб-сайт был разработан другой стороной, которая может удаленно протестировать нашу базу данных. Они работают под управлением v7r1, и у них не было никаких проблем при использовании сайта с нашей базой данных. Веб-сайт получает доступ к данным через ODBC, и я попытался перенастроить DSN. Один из сотрудников службы поддержки даже попросил меня зарегистрировать их точную конфигурацию ODBC с файлом .reg, но все равно ничего. И у них, и у меня закончились идеи, поэтому на данный момент мы обратились к справочной ссылке. Мне довелось работать на другом веб-сайте, который использует тот же сервер для запросов, и соединение ODBC на этом сайте имело такое же поведение ... имена и любые другие поля поиска кажутся чувствительными к регистру. Я знаю, поскольку меня неожиданно удивило, что мой сайт не работает, мой сайт НЕ был чувствителен к регистру до обновления v6r1. Мы также используем стороннее приложение для выполнения SQL-запросов, и в том же DSN запросы в этом приложении НЕ чувствительны к регистру. Как видите, я не могу найти никакой корреляции. Кто-нибудь знает о проблемах с IBM DSN или чувствительности к регистру в серверах / файловых системах IBM, которые могут вызвать это для определенных запросов?
Если подозреваемым является драйвер ODBC, проверьте DSN. Перейдите на вкладку «Язык», а затем выберите тип сортировки «Сортировка по идентификатору языка». Затем выберите свой языковой идентификатор. Значение по умолчанию - «Сортировка по * HEX значениям».
Если подозреваемым является сервер IBM i, попросите администратора проверить свойство SRTSEQ серверных заданий (возможно, QZDASOINIT), чтобы установить для него значение * LANGIDSHR. По умолчанию * HEX. Ясно, что это повлияет на ВСЕ доступ ODBC к серверу IBM, а не только на ваш доступ. Но если так было до апгрейда, наверное, лучше было бы поставить обратно.
Это могло бы быть более прозрачным, если бы запросы обрабатывали моноблочный корпус явно. Поэтому вместо ... WHERE CUSTNAME LIKE 'JONES%' ... это будет ... WHERE UPPER (CUSTNAME) LIKE 'JONES%' ...