Как выполнить поиск без учета регистра в UniData с помощью Uniquery

Question

К сожалению, мне нужно поработать с системой баз данных UniData IBM. Я делаю это из кода C# с UniObjects для.net.

Я создаю страницу поиска ASP.NET, которая имеет одно поле поиска. У меня проблема в том, что критерии чувствительны к регистру. Как я могу выполнить поиск без учета регистра с UniQuery?

Я мог бы вернуть все и достичь нечувствительности к регистру в своем операторе Linq to XML, но это приведет к проблемам с производительностью, поскольку это не очень эффективно.

Вот код, который я написал:

using IBMU2.UODOTNET;
using UniObjectsHelper;
using System.Xml.Linq;
...
    void DoSearch()
    {
        XElement xml;

        using (UniSession us = UniHelper.OpenSession((UniDataConfig)ConfigurationManager.GetSection("unidataConfig")))
        {
            UniCommand cmd = us.CreateUniCommand();

            // this is probably insecure. I will deal with that later
            cmd.Command = string.Format(@"LIST UT.OPERS WITH @ID = ""{0}"" OR WITH LAST.NAME = ""{0}"" OR WITH FIRST.NAME = ""{0}""  OR WITH MIDDLE.NAME = ""{0}"" LAST.NAME FIRST.NAME MIDDLE.NAME TOXML", txtSearch.Text);
            cmd.Execute();

            xml = XElement.Parse(cmd.Response);
        }

        gvwResults.DataSource = from x in xml.Descendants("UT.OPERS")
                                select new
                                {
                                    User = x.Attribute("_ID").Value,
                                    FirstName = x.Attribute("FIRST.NAME").Value,
                                    LastName = x.Attribute("LAST.NAME").Value,
                                    MiddleName = x.Attribute("MIDDLE.NAME").Value
                                };
        gvwResults.DataBind();                                
    }

РЕДАКТИРОВАТЬ

Я нашел это:

UDT.OPTIONS 92

U_INSENSITIVE_MATCH

Этот параметр влияет на запросы, выполняемые для данных, которые содержат преобразования в стиле Pick® в определениях словаря. Коды обработки в стиле Pick® MCL, MCT и MCU преобразуют регистр символов. Эти преобразования применяются к данным перед сравнением и выбором, таким образом, исключая совпадающие символы разного регистра. UDT.OPTIONS 92 заставляет LIKE преобразовывать как данные, так и литерал, на котором основан выбор, так что выбор фактически не основан на регистре.

Я действительно не знаю, что такое "коды обработки в стиле Pick® MCL, MCT и MCU". Кто-нибудь может объяснить?

Answer 1

Вам не нужно создавать какие-либо вычисляемые столбцы или элементы словаря для поиска без учета регистра в Unidata/Datatel.

Я нашел некоторую документацию, в которой предлагается включить опцию 92, и мне следует использовать код MCL и функцию OCONV. Я не мог заставить его работать. НО! Я был на правильном пути!

Я даже получил ответ относительно запросов без учета регистра от инженера Rocket Software (компании, которая получила UniData от IBM):

Технически нет, здесь нет оператора выбора без учета регистра.
Однако вы можете делать то, что заставляет ваши операторы UniQuery вести себя одинаково.
Вы можете создать элемент словаря для атрибута, который преобразует его в верхний или нижний регистр. В приведенном ниже примере элемент словаря преобразует поле 2 во все строчные буквы.

ПРИМЕР:

AE DICT VOC F2.CASE
001: D
002: 2
003: MCL
004:
005: 15 л
006: S

UDT.OPTIONS 92 заставляет словари типов MCU, MCL и MCT вести себя по-разному. Вы можете прочитать об этом в справочнике команд UDT.OPTIONS, доступном в онлайн-документации UniData.

Таким образом, он говорил о том, чтобы пойти на неприятности заранее, чтобы создать эти дополнительные элементы словаря, что я не могу соблюдать. Это просто слишком много усилий. Спасибо Скотту Кросби из Alamance Community College за то, что он прислал мне следующее:

Чувак, ты спрашивал это давным-давно, и я никогда не возвращался к тебе. Я помню, как вы спрашивали, когда я просматривал какой-то код, работая над проектом. Ваш вопрос касался запросов к базе данных Unidata, а точнее - использования поиска с учетом регистра. Единственное решение, которое я придумал, - это использовать OCONV с кодом MCL, чтобы Unidata заставляла strtolower обрабатывать данные перед сравнением. Вы, наверное, уже нашли способ сделать это, но здесь это все равно!

$ query = "LIST PERSON WITH EVAL \" OCONV (PERSON.EMAIL.ADDRESSES, 'MCL') \ "LIKE" ". strtolower (электронная почта $). "PERSON.EMAIL.ADDRESSES ID.SUPP NOPAGE TOXML ELEMENTS WITHDTD";

По сути, я хотел найти PERSON.EMAIL.ADDRESSES для $email (из приложения PHP), чтобы узнать, существует ли он в базе данных. Спасибо, Скотт К. Кросби

Итак, когда вы берете вещи из PHP и XML из его примера, команда выглядит так:

LIST PERSON WITH EVAL"OCONV(PERSON.EMAIL.ADDRESSES,'MCL')" LIKE '[e-mail]' PERSON.EMAIL.ADDRESSES ID.SUPP NOPAGE TOXML ELEMENTS WITHDTD";

Синтаксис WITH EVAL"OCONV(FILE.FIELD.NAME,'MCL')" LIKE "текст поиска в нижнем регистре" дает нам то, что мы хотим. Это не самая красивая вещь в мире, но это легко сделать, и это работает.

Answer 2

Я немного огляделся и не могу найти регистр без учета SELECT, LIST, или же SORT команда в UniQuery, ни переключатель / настройка, чтобы изменить чувствительность к регистру. Невероятно, а?

Вот идея, хотя:

Ты можешь позвонить .ToLower на txtSearch.Text и установите код преобразования (атрибут 3) в MCL в UT.OPERS словарь для LAST.NAME, FIRST.NAME и др. Яблоки с яблоками.

Одна вещь, которую я обнаружил при тестировании, это то, что это работает, только если вы окружаете каждый из ваших критериев выбора подстановочными скобками, например: ...WITH LAST.NAME = ""[{0}]""

Если вы не хотите изменять свои словари акций для LAST.NAME и т. д. вы можете создавать новые элементы словаря и добавлять к ним префикс L_ (или что-то), чтобы отличить их.

РЕДАКТИРОВАТЬ:

• MCL преобразует текст в нижний регистр
• MCT преобразует текст в соответствующий регистр
• MCU преобразует текст в верхний регистр

Если вы поместите любой из этих кодов преобразования "Pick-style" в атрибут 3 словаря, который описывает ваше поле, преобразование будет выполняться каждый раз, когда вы используете словарь.

Например, если вы добавили "MCL" в свой LAST.NAME поле, когда ты сделал LIST UT.OPERS LAST.NAME все фамилии будут отформатированы в нижнем регистре независимо от того, как на самом деле хранятся данные.

Я полагаю, что UDT.OPTION 92 делает то, что литерал в ваших критериях выбора также конвертируется с использованием того же кода преобразования, что и в словаре, что дает вам нечувствительность к регистру.

SELECT UT.OPERS WITH LAST.NAME = "Smith"

Будет преобразован в:

SELECT UT.OPERS WITH LAST.NAME = "smith" 

до сравнения произошло.

По сути, то, что UDT.OPTION 92 сделает для вас, - это запретит вам звонить .ToLower в идее, которую я представил выше. Не много денег для доллара, ИМХО.