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

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

2 голосов
/ 28 октября 2009

К сожалению, мне нужно поработать с системой баз данных 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();                                
    }

EDIT

Я нашел это:

UDT.OPTIONS 92

U_INSENSITIVE_MATCH

Этот параметр влияет на запросы, выполняемые на данные, содержащие стиль Pick® преобразования в словарных определениях. Коды обработки в стиле Pick® MCL, MCT и MCU преобразуют регистр персонажи. Эти преобразования применяется к данным до сравнение и отбор, таким образом пропуская совпадающие символы непохожих дело. UDT.OPTIONS 92 делает НРАВИТСЯ преобразовать как данные, так и буквальные на котором основан выбор, так что выбор, по сути, не на основании кейса.

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

Ответы [ 2 ]

1 голос
/ 16 марта 2010

Вам не нужно создавать какие-либо вычисляемые столбцы или элементы словаря для поиска без учета регистра в 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 DB, но более конкретно, используя регистрозависимый поиск. Единственное решение, которое я придумал, это использовать OCONV с кодом MCL, чтобы заставить Unidata, чтобы сделать strtolower на данных перед сравнением. Ты наверное уже нашел способ сделать это, но вот оно в любом случае!

$ query = "СПИСОК ЧЕЛОВЕКА С EVAL \ "OCONV (PERSON.EMAIL.ADDRESSES 'MCL') \" LIKE '". Strtolower ($ email)."' 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 'some.lower.case@email.address' PERSON.EMAIL.ADDRESSES ID.SUPP NOPAGE TOXML ELEMENTS WITHDTD";

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

1 голос
/ 28 октября 2009

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

Вот идея:

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

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

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

EDIT:

  • 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 в идее, которую я изложил выше. Не много денег для доллара, ИМХО.

...