Глобальный поиск, не ищет штрихкоды

[AndyD]

Цитата:

Сообщение от glibs

Если у вас есть представление насколько медленные Аксаптовские функции парсинга текстовых переменных, и насколько быстро в принципе может происходить вставка данных в реляционной СУБД, то можете себе это представить.

По-моему, здесь как раз тот случай, когда на сколько бы ни был тормозным x++, но соединение с базой - еще тормознутее

Помимо непосредственно операций вставки в коде еще много поисковых запросов и запросов на удаление.

К примеру, удаление из таблицы sysSearchPath

    delete_from sysSearchPath
        where sysSearchPath.Design     == design     &&
              sysSearchPath.LanguageId == languageId &&
              sysSearchPath.URL        == URL;

Вроде бы, выглядит все хорошо - один запрос, индексы используются.
Но вот только на таблице висит DeleteAction Cascade для sysSearchRef. И тут же дополнительно появляется неявный запрос на выборку из sysSearchPath с последующим удалением из sysSearchRef.

Или запрос

sysSearchName = SysSearchName::findRecId(word, design, languageId);

который вызывается для каждого слова, входящего в индексируемые поля
Опять-же - поиск по индексу, на таблице включено кэширование (Found).
Но если количество слов окажется больше размера кэша (2000 записей для сервера, чего при построении индекса по большим таблицам слишком мало), то запросы уже будут идти не в кэш, а на сиквел. И есть подозрение, что при этом кэш начнет активно обновляться.

В общем, регулярные выражения в Аксапте конечно неторопливы, но основные тормоза, в данном случае, не в них

Что бы убедиться, что проблема действительно в количестве обращений к базе данных, переписал код на использование класса System.Text.RegularExpressions.Regex. По тестам чистого разделения строки на слова производительность этого класса раз в 20 была выше на моей системе, чем TextBuffer, плюс еще сделал кое-какую оптимизацию кода.
Но на итоговую скорость выполнения это сказалось крайне слабо - время выполнения улучшилось максимум процентов на 10

Цитата:

Сообщение от glibs

И еще. В настройке таблиц на первой закладке есть поле типа "Инкрементный" (я русский интерфейс не помню, извините). Так вот если у вас там не стоит галочка — то это плохо. Механизм индексации в таком случае очень неэффективен. Он постоянно переиндексирует все данные. Если же галка стоит, то он переиндексирует только измененные с момента последней индексации записи. При первой индексации это не существенно, но если вы остановите агента и запустите снова, то эффект будет принципиально разным.

Галка показывает, есть на индексируемой таблице поле ModifiedDateTime или нет. Это дисплейный метод и влиять на него мы может только включением/выключением ModifiedDateTime на таблице
(Просто уточняю на всякий случай)