Полнотекстовый поиск в 1С. №1 Грабли в динамических списках

Публикация № 1056842

Администрирование - Администрирование данных 1С - Поиск данных

полнотекстовый поиск администрирование разработка обновление платформы

Полнотекстовый поиск в 1С и все что с этим связано. Часть №1: особенности работы в динамических списках.

Найти, найти, найти

Поиск - одна из самых важных задач, которую решает платформа 1С. Чем больше размер базы, массив данных в ней, тем острее эта задача.

Стандартные возможности поиска средствами СУБД (будь это файловая база или SQL Server, PostgreSQL) не всегда работают эффективно, а уж тем более не могут удовлетворять условиям гибкого поиска по текстовому содержимому объектов. Да, поиск по индексированным полям решает множество задач, но вот гибкий поиск по текстовому содержимому на уровне СУБД не всегда работает на нужном уровне, особенно если речь идет о платформе 1С. Тут на помощь приходит полнотекстовый поиск платформы!

В серии из нескольких статей мы коснемся различных аспектов работы полнотекстового поиска в контексте платформы 1С. Разберемся зачем он вообще нужен, как работает, где используется и, самое главное, как мы можем его использовать. И хотя на первый взгляд серию статей нужно было бы начать с теории и простейших примеров, но не в этот раз. Мы начнем с "граблей" и боли. Чтобы было интересней.

Ранее на эту тему публиковался инструмент "Мастер полнотекстового поиска", с помощью которого можно управлять настройками полнотекстового индекса и выполнять некоторые расширенные действия. Теперь пришло время для новых публикаций, где мы глубже копнем в теорию и практику использования полнотекстового индекса и даже выйдем немного за границы платформы. Но всему свое время.

Это первая часть публикации по этой теме. Появление продолжения будет зависеть от Вас. Будет интерес - будет и материал :)

И так, на старт, внимание....

Марш! Начнем с проблемы

Вот простая ситуация. В информационной базе создано почти 1 миллион документов "Заказ клиента". Это не плохо и не хорошо само по себе. Менеджеры по продажам каждый день работают со списком заказов, ищут в нем значения по различным полям, подбирают заказы в реализации или отчеты для отборов. В общем, поиск заказов клиентов - операция, которая выполняется даже чаще, чем их создание.

Если база в каком-то смысле "запущена" и не обслуживается в полной мере, то полнотекстовый поиск в ней может быть просто недоступен. Например, он может быть включен, но регламентные задания обновления и слияния полнотекстового индекса отключены. Или же использование полнотекстового индекса полностью выключено. А бывает еще хуже - полнотекстовый индекс используется, задания обновления индекса не включены, но при этом есть неактуальный индекс многолетней давности. В итоге поиск работает, но не находит все значения.

В списке заказов клиента поиск выполняется несколькими способами (чаще всего). Например, нужно найти заказы клиента, у которых в номере есть "85245" и имя клиента содержит слово "Сириус". Вот как это может выглядеть при выключенном / нерабочем полнотекстовом поиске:

 
 По нажатию Ctrl+F попадаем в поле поиска (обычно справа вверху) и набираем нужное значение.

Вот так выглядит стандартный поиск, который сейчас по умолчанию добавлен во все формы списков средствами платформы.

Выглядит достаточно удобно, т.к. искомые значения вводим в одно поле и ждем результата. Да и скорость вроде бы нормальная. Зачем вообще полнотекстовый поиск? К этому мы вернемся чуть позже.

 
 Выделяем нужную колонку и после нажатия Alt+F ищем по нужному значению.

Альтернативный способ, который раньше был основным и вызывался через Ctrl+F - это поиск значений по отдельным колонкам. Да, раньше не было единого поля поиска над списком, но я думаю Вы и так знаете. Вот так это выглядит.

Этот способ визуально даже быстрее предыдущего. Далее мы также разберем почему. Полнотекстовый индекс в таком варианте никак не используется.

Есть и другие способы поиска (через настройку списка, например), но сейчас это не принципиально. Поэтому рассматривать их не будем.

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

Пример №1: Ищем с помощью единого поля поиска

В первом случае, когда мы выполняли поиск через единое поле ввода, платформа 1С сгенерировала очень интересные запросы к базе данных. Да, их было несколько и они очень объемные. Оставил комментарии в той части, которая важна для нашей темы.

 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №1
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №2
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №3
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №4

И так, платформа 1С сгенерировала аж 4 запроса для поиска по вхождению частей строки "Сириус 85245". Несмотря на то, что SQL-запросы похожи между собой, на самом деле они выполняют разную работу. Вот основные действия платформы в этом случае:

  • Платформа формирует SQL-запрос динамического списка и добавляет в него фильтры в соответствии с частями строки поиска.
  • Можно выделить основные отборы:
    • Отбор по разделителю данных.
    • Далее идет отбор по вхождению строки "Сириус" во все строковые поля, которые выводятся в динамический список. Причем это не только поля заказа клиента, но и других таблиц (регистра "Состояния заказов клиента", "Состояние ЭП" и др.
    • После идет отбор по вхождению строки "85245" как в строковые поля списка (как в пункте выше), так и устанавливается отбор на числовые поля списка (процент долга, процент оплаты и др.). Причем на числовые поля отборы устанавливаются бессмысленные (значение в полях может быть меньше, равно или больше искомого значения). Есть другие варианты? :)
  • Далее в зависимости от 1 из 4 запросов устанавливается особый отбор:
    • В первом запросе по определенной дате и ссылке, которая должна быть больше или равна определенного значения.
    • Во втором запросе по дате и по ссылке, которая меньше определенного значения.
    • Отбора по ссылке уже нет. Только по дате документа, которая должна быть больше определенного значения.
    • Отбора по ссылке уже нет. Только по дате документа, которая должна быть меньше определенного значения.

Таким образом платформа 1С пытается разделить получение данных на части:

  1. Получаем данные на определенную дату вплоть до секунды, но с разными отборами по ссылке.
  2. Далее получает данные по тем документам, у которых дата больше ранее отбираемого значения.
  3. На последнем этапе получает данные по документам, у которых дата меньше отбираем значения.

На тех этапах, когда в запросе имеется отбор на равенство конкретной дате документа все в принципе хорошо. Это селективный отбор и индекс по дате документа позволяет получать данные очень эффективно, никаких проблем. Но вот в остальных случаях, когда отбора на равенство по дате нет и вместо него появляется отбор по дате больше (или равно) и меньше определенного значения - тут начинается веселье. Взгляните на монструозный план запроса, который был сгенерирован СУБД для запроса, где дата документа больше определенного значения (см. запрос №3).

 
 Страшный план запроса

Для конкретно нашего примера запрос "съел" весомые ресурсы:

  • Выполнялся примерно 8 секунд (CPU 8157 мс).
  • Прочитаны все записи таблицы заказов клиентов.
  • Использовал 10119361 страниц памяти (reads). А если вспомнить что каждая страница 8 КБ, то...

В общем, как видно стандартный поиск в списках через единое поле ввода может создавать тяжелые по использованию ресурсов запросы, которые могут поспорить со многими тяжелыми аналитически отчетами. Что самое удивительное - в нашем примере платформа 1С сгенерировала два тяжелых запроса: один с отбором по дате больше указанной даты документа, а второй с отбором меньше заданного значения. По затраченным ресурсам они практически не отличаются. 

А ведь у нас искусственный пример, где поиск выполнялся одним пользователем. В многопользовательской среде все куда хуже!

Пример №2: Ищем с помощью отборов в отдельных колонках

Тут все значительно проще в части диагностики, чем в первом примере. Если мы устанавливаем отбор по двум колонкам через Altf+F, то платформа также генерирует 4 запроса по тем же принципам, что и выше. Но в этот раз отбор по искомым значениям в SQL-запросе иной. Не буду приводить все сформированные SQL-запросы, остановимся лишь на 1 самом "тяжелом".

 
 Тяжелый запрос с отбором по 2 колонкам

Запрос стал проще и вместо страшных комбинаций условий отборов из предыдущего примера у нас появились конкретные условия по номеру документа и имени клиента (партнера). Запрос стал "кушать" меньше ресурсов:

  • Время выполнения примерно 2 секунды (CPU 2234 мс)
  • Прочитаны все записи таблицы заказов клиентов.
  • Общее количество прочитанных страниц 3514415.

Фактически, запрос выполняется в 4 раза быстрее, чем то что было выполнено в примере ранее. Но запрос все равно "съедает" непростительный объем ресурсов, особенно критичный для многопользовательской информационной системы.

Но можно ли такие операции поиска как-то оптимизировать?

Что обычно приходит в голову

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

Что это значит? Да очень просто:

  • Поиск через Ctrl+F и Alt+F больше невозможно выполнить. Стандартное поле поиска вверху списка убирают полностью.
  • Также запрещают использовать гибкий поиск через "Все действия -> Настроить список"
  • В шапку формы списка выводят несколько полей, по которым можно выполнять поиск. При этом отборы устанавливаются строго определенного типа (равно, начинается с...). Делается это для того, чтобы условия отборов могли использовать индексы. Как известно, условия "ПОДОБНО %<тут значение>%" не используют индексы.

Профит!

Но работает это только в том случае, если бизнес согласен на такое. Тем более нужны будут доработки (даже если это делается расширениями). Да и сделать это во всех списках не всегда возможно, а еще остается поиск при вводе по строке...

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

А вот и полнотекстовый поиск!

Как Вы могли увидеть, гибкий поиск по текстовому содержимому объектов обрабатывается СУБД не самым лучшим образом. И это нормально! Оператор поиска "LIKE" и не предназначен для такой задачи. На стороне СУБД для таких целей есть собственные движки полнотекстового поиска, которые платформа 1С не использует. Вместо этого фирма "1С" пошла своим путем и создала собственный движок для полнотекстового поиска данных, который мы и можем использовать для оптимизации подобного рода операций.

Тем более по умолчанию подразумевается, что поле поиска в тех же динамических списках будет использовать именно полнотекстовый поиск, а не возможности СУБД. Во многих базах (файловых и клиент-серверных) полнотекстовый индекс строится и обслуживается с помощью регламентных заданий и пользователи, разработчики, админы об этом могут просто не знать. Работает - не трогай, как говорится :).

Но чтобы убедиться, что построение и использование индекса полнотекстового поиска исправит наши тяжелые запросы выше - проведем эксперимент. Построим индекс полнотекстового поиска (я использовал инструмент "Мастер полнотекстового поиска", но никто не мешает Вам использовать стандартные обработки платформы). Размер индекса для всей базы с почти миллионом заказов клиента получился равным 7 ГБ.

Но рано радоваться, нужно проверить поможет ли полнотекстовый индекс в нашем конкретном случае.

Еще один эксперимент

А теперь выполним поиск через Ctrl+F как это делали ранее и посмотрим что на уровне базы данных. Повторный поиск через Alt+F делать не будем, т.к. поиск по конкретным колонкам всегда выполняется с помощью средств СУБД. А вот поиск через поле поиска - то что нужно.

Ничего не изменилось! Платформа генерирует те же самые тяжелые SQL-запросы, что в самом первом примере. Полнотекстовый поиск никак не используется! Даже визуально видно, что поиск занимает такое же количество времени. Давайте попробуем кое-что изменить.

Попробуем выполнить поиск только по части номера - "85245". Сразу скажу результат - снова ничего не изменилось. Платформа также настойчиво генерирует "страшные" SQL-запросы и игнорирует полнотекстовый индекс.

Идем дальше и через "Еще -> Изменить форму" оставляем в списке только колонки "Номер", "Дата", "Сумма", "Клиент". Эти поля 100% есть в составе заказа клиента и не получаются из сторонних таблиц, как например статусы заказа. Пытаемся выполнить поиск еще раз и...

Поиск отработал практически мгновенно! То, что нам нужно! При этом на стороне базы данных сформированы также 4 аналогичных запроса, но в них появились отборы по ссылкам. Это порции данных, которые были найдены с помощью полнотекстового поиска.

 
 Запрос с фильтрами по результатам полнотекстового поиска

А вот если попробовать ввести строку поиска "Сириус 85245", то полнотекстовый поиск снова игнорируется и платформа опять (или снова) лезет с тяжелым запросом к базе данных.

Что все это значит?

В официальной документации сказано, что использование полнотекстового индекса в поиске динамического списка имеет следующие нюансы:

  1. Полнотекстовый поиск должен быть включен для всех объектов, которые участвуют в запросе списка и могут использоваться в качестве основной таблицы. При этом все поля, выводимые в список, должны также быть с включенным полнотекстовым поиском.
  2. Полнотекстовый индекс должен обслуживаться должным образом (не забыть настроить регл. задания).
  3. Поиск выполняется по колонкам, которые отображаются в таблице.
  4. Поиск по ссылочным полям выполняется по полям представления, которые также должны быть добавлены в полнотекстовый индекс.
  5. Сначала выполняется поиск по основной таблице. К результатам полнотекстового поиска добавляются все непроиндексированные ссылки из основной таблицы. Результат полнотекстового поиска используется для отборов по ключевым полям.
  6. При возникновении ошибок полнотекстового поиска режим поиска переключается на стандартных механизм, то есть с помощью средств баз данных.
  7. Если есть отборы "Равно", то они в любом случае добавляются в финальный запрос с учетом отбора по результатам полнотекстового поиска.
  8. Строка поиска разбивается на слова (максимум 20) и не должна превышать 1000 символов. Пробел и табуляция - разделители слов. Для каждого фрагмента создается свой набор условий по ИЛИ. Все фрагменты соединяются в И.

Часть из этих правил Вы могли увидеть в примерах выше, в т.ч. разбиение условий на фрагменты в запросах и так далее. Но почему в нашем случае полнотекстовый поиск не срабатывал, если указать имя партнера в строке поиска?

Причина для этого была только одна: в запросе имеются условия соединения и поля с регистрами сведений со статусами заказов и ЭП. Эти таблицы не проиндексированы. Причем эти поля использовались в запросе даже если убрать их из списка выводимых полей через "Изменить форму". Решение - упростить запрос в списке, удалив эти регистры, и все должно заработать. Ну или проиндексировать их.

Все так просто?

К сожалению, нет. Именно в этом примере нам повезло и мы нашли причину. Но бывают ситуации куда сложнее. Ситуация еще может усугубляться особенностями версии платформы и режимом совместимости. Например:

  • Платформа 8.3.12 с конфигурацией с совместимостью 8.3.4 в некоторых случаях может вообще не выполнять поиск. Также в этой версии не работает ограничение по метаданным для полнотекстового поиска. Если фильтр установлен, то возвращается пустой результат.
  • Также в одной из новых версий платформ не выполнялся полнотекстовый поиск по ссылочным полям, только по непосредственно полям основной таблицы.

Отлаживать такое поведение очень сложно и часто поиск причин выполняется по знаменитой методике "Метод тыка". А самое тяжелое здесь то, что даже типовые конфигурации не гарантируют, что в динамических списках будет работать полнотекстовый поиск. В примерах выше была конфигурация УТ 11. А если там все и работает корректно, то кто знает когда это может сломаться...

В высоконагруженных системах поиск в динамических списках может быть очень опасен, создавая повышенную нагрузку на всю систему в самых непредсказуемых проявлениях. Полнотекстовый поиск то может работать, а может и нет :) Особенно после обновления платформы!

Только начало

Конечно, может стоило начать серию статей по полнотекстовому поиску в 1С с базовых теоретических знаний и примеров. Но на мой взгляд лучше сразу начать с хардкора.

В следующих статьях, если данная тема будет интересна сообществу, мы рассмотрим такие темы как:

  • Программная работа с полнотекстовым поиском
  • Сопровождение полнотекстового индекса и контроль его работы
  • Продвинутая отладка работы полнотекстового поиска в списка и других местах конфигурации
  • Как используется полнотекстовый поиск в типовых конфигурациях
  • Особенности обновления платформы в контексте полнотекстового поиска
  • Полнотекстовый поиск нестандартными средствами
  • Несколько кейсов по производительности платформы 1С при работе с полнотекстовым индексом
  • Как можно сломать полнотекстовый индекс на пустом месте.

А Вы используйте штатный полнотекстовый поиск 1С? Дайте знать в комментариях :) Любые вопросы, предложения по этой теме приветствуются :)

Другие ссылки

Авторские разработки

 
 Другие разработки

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tormozit 5958 18.07.20 23:56 Сейчас в теме
Опечатка в SQL запросе №1
динаического -> динамического
YPermitin; +1 Ответить
2. PerlAmutor 106 19.07.20 08:19 Сейчас в теме
В ERP в форме списка контрагентов и номенклатуры используется программный полнотекстовый поиск. Был случай, пользователи начали жаловаться, что при поиске некоторых контрагентов выдается ошибка, в то время как другие ищутся без проблем. Выяснилось, что при использовании методов полнотекстового поиска возвращалось количество найденных записей, но при этом в результатах было пусто. При попытке обхода результата в цикле количество записей использовали как индекс, который выходил за границы диапазона. Причем другого способа проверки количества результатов полнотекстового поиска в платформе нет. После полного перестроения индекса проблема ушла.

Я тут наткнулся еще на одну нерешенную задачку. У меня есть форма выбора с динамическим списком, причем поле там всего одно - строковое. При передаче в форму выбора параметра "ТекущаяСтрока" ничего не происходит, т.к. значение - не ссылочного типа, а строкового.

Как же найти в динамическом списке нужную строку и спозиционироваться на неё?
YPermitin; +1 Ответить
3. YPermitin 9679 19.07.20 08:39 Сейчас в теме
(2) случаи, когда только перестроение индекса помогало - были. К сожалению, часто.

А какой там запрос в списке? Ссылку нельзя в запросе получить и сделать обязательной к получению? Тогда по неи и позиционироваться.
7. PerlAmutor 106 19.07.20 19:59 Сейчас в теме
(3) Там внешний источник данных, ссылок нет никаких, только строковый идентификатор в качестве уникального значения. От ссылочных полей отказался по той причине, что таблица периодически перестраивается и записи таблицы могут получить идентификаторы, которые день назад принадлежали другим записям. 1С все это дело пытается кэшировать и из-за этого возникают проблемы с получением представлений. Видим на экране одно, а внутри содержится другое. Искали одно, а получили другое.
10. YPermitin 9679 20.07.20 10:34 Сейчас в теме
(7) тут все усложняется. Обычно позиционирование по ссылке выполняется. А по строке... Надо "химичить".
14. Yashazz 3408 21.07.20 00:54 Сейчас в теме
(7) Попробуйте поиграть с "Вид ключа" в режиме "Значение поля" и с "Поле ключа", например, в явном виде указать в качестве вида именно это строковое поле; тогда ТекущаяСтрока и на клиенте, и на сервере вернёт именно ключевую строку. Ну, естесссно, если строки уникальны и годятся на ключ. Если нет, тогда ставьте вид ключа "Номер строки" и выкручивайтесь через СКД дин.списка и её текущие настройки.
...сделать, что ли, об этом публикацию...
4. ivanov660 2236 19.07.20 09:39 Сейчас в теме
Согласен, напрягает сильно этот бизнес со своим поиском в динамических списках по "трем символам", возможности добавления полей через две точки, отборов, группировок и сортировок по не предназначенным полям. Иногда хочется установить формы отчетов с жесткими отборами и ограничением первые 50)
Yashazz; JohnyDeath; YPermitin; +3 Ответить
5. YPermitin 9679 19.07.20 10:08 Сейчас в теме
6. muskul 19.07.20 10:13 Сейчас в теме
Всегда были проблемы с этим поиском. то номенклатура не ищется то клиенты.
YPermitin; +1 Ответить
8. Yashazz 3408 19.07.20 22:00 Сейчас в теме
Юрию респект за хорошую статью, а инструменту платформы - категорическое "фу", проще своими силами эмулировать, чем штатное юзать.
EliasShy; YPermitin; +2 Ответить
9. bulpi 175 20.07.20 10:33 Сейчас в теме
Эта статья в очередной раз подтвердила мою уверенность в том, что полнотекстовой поиск - фигня, и использовать его не надо.
11. YPermitin 9679 20.07.20 10:35 Сейчас в теме
(9) я постараюсь переубедить в следующих публикациях.

Все таки использовать его можно и нужно.
user633166; +1 Ответить
12. user633166 10 20.07.20 13:01 Сейчас в теме
(11) Спасибо за детальный разбор, но соглашусь с (8) и (9) - уверенности в инструменте такие поиски причин, почему что-то не находится, хотя оно есть, не добавляют. И где "ждут тебя эти грабли"? Когда "прилетят"?

А следующую публикацию ждём...
mvxyz; Yashazz; YPermitin; +3 Ответить
16. Yashazz 3408 21.07.20 01:08 Сейчас в теме
(12) Да, если мы с уровня "слияние/обновление индексов и разница между ними" перейдём к тезаурусам, стоп-словам и вообще АОТЕЯ в 1С, то я "за" двумя руками!
13. YPermitin 9679 20.07.20 23:41 Сейчас в теме
(0) Вот еще интересная публикация по этой теме: https://infostart.ru/public/1267438/
15. Yashazz 3408 21.07.20 00:57 Сейчас в теме
(13) Неее. Мне кажется, там решение частного случая в рамках документации...

И вообще, пока нет программных средств управления полнотекстовым, или хотя бы настройки индексации (словари, размеры порций, порядок слияния, размещение, я уж не говорю про шкалу релевантности, уровень шума и синтагматические связки), он остаётся вещью в себе и чёрным ящиком.
Ощущение, что портировали некую хрень, прикрутили к платформе, да сами не сильно в ней разобрались. Прям иногда интересно, что это было - Сфинкс, или что-то на основе Solr'a...
YPermitin; +1 Ответить
17. ITSolncev 22.07.20 15:58 Сейчас в теме
Очень детально и наглядная подача, спасибо за статью! +
YPermitin; +1 Ответить
18. omen3333 4 27.07.20 21:56 Сейчас в теме
Спасибо за статью.

Работал в фирме с двумя десятками УТшек, в двух из которых тоже была тысяча тысяч заказов, индекс полнотекстового поиска в каждой из таких баз весил > 25Гб. На время слияния индекс занимал ещё столько же места. Т.е. при одновременном слиянии индекса во всех базах, сервер периодически оставался без места на дисках. Долго пытались его облегчить, пришлось отключить. Но там старая платформа было, 8.3.12-13.

А поиск в списке заказов по не индексированным колонкам иногда надолго (пока не грохнешь зависший сеанс) вешал проц. под 90%, лечилось поиском виноватого пользователя и расспросами куда нажимал.
YPermitin; +1 Ответить
Оставьте свое сообщение

См. также

Просмотр и анализ журнала регистрации (отчет на СКД) Промо

Журнал регистрации v8::УФ v8::СКД 1cv8.cf Абонемент ($m)

Отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации. В отчете можно использовать возможности СКД для вывода отчета в различных вариантах (список, таблица, диаграмма). Поддерживаются все возможности журнала регистрации (фильтры, получаемые колонки, максимальное количество записей).

5 стартмани

25.07.2013    63850    572    YPermitin    52    

Полнотекстовый поиск в 1С. №2 Самое основное для разработчика

Поиск данных v8 1cv8.cf Бесплатно (free)

Полнотекстовый поиск в 1С и все что с этим связано. Часть №2: программное использование и некоторые нюансы при разработке.

02.09.2020    2912    YPermitin    4    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    4740    YPermitin    22    

Ускоряем полнотекстовый поиск в динамических списках

Поиск данных v8 1cv8.cf Россия Бесплатно (free)

Сам являюсь пользователем УТ 11.4 и при обращении пользователей пользуюсь поиском, и как многие пользователи, сталкиваюсь с медленным поиском в динамических списках. В статье приведу пример кода, который поможет исключить из поиска лишние колонки, ускорит поиск и освободит кучу ресурсов у сервера.

20.07.2020    3314    PRO100_NigGaZ    10    

Полнотекстовый поиск по значениям реквизитов Промо

Чистка базы Поиск данных Обработка справочников v8 Абонемент ($m)

Обработка расширяет возможности Полнотекстового поиска, позволяя искать похожие элементы в ЛЮБЫХ Справочниках ЛЮБОЙ конфигурации по проценту совпадения значений выбранных реквизитов. Работает в Обычном и Управляемом режиме!!

1 стартмани

25.12.2013    38088    45    vladim-kul    8    

Экспорт журнала регистрации. Набор инструментов (приложения + исходный код)

Прочие инструменты разработчика Журнал регистрации Абонемент ($m)

Набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux (SQL Server, PostgreSQL, MySQL). Готовые приложения и исходный код.

10 стартмани

26.05.2020    4327    15    YPermitin    0    

История работы пользователей (отчет на СКД)

Администрирование СУБД v8 v8::УФ v8::СКД 1cv8.cf Абонемент ($m)

Отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).

2 стартмани

14.03.2020    5654    56    YPermitin    26    

Информация о пользователях информационной базы (отчет на СКД)

Администрирование данных 1С Роли и права v8 v8::Права v8::СКД 1cv8.cf Абонемент ($m)

Два простых отчета по пользователям информационной базы и информации по ним.

1 стартмани

02.03.2020    5399    19    YPermitin    8    

Технические проверки данных регистров бухгалтерии (отчет на СКД)

Администрирование данных 1С Бухгалтерский учет Механизмы бухгалтерского учета v8::БУ 1cv8.cf БУ Абонемент ($m)

Отчет для технических проверок данных бухгалтерских регистров.

5 стартмани

25.02.2020    5032    14    YPermitin    2    

Мастер полнотекстового поиска

Поиск данных v8 v8::УФ 1cv8.cf Абонемент ($m)

Набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.

2 стартмани

07.02.2020    7794    61    YPermitin    28    

Помощник работы с идентификаторами объектов

Прочие инструменты разработчика Поиск данных v8 1cv8.cf Абонемент ($m)

Инструмент для расширенного анализа идентификаторов объектов.

2 стартмани

24.01.2020    8330    29    YPermitin    29    

Транслятор запросов 1С в SQL

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 v8::Запросы 1cv8.cf Абонемент ($m)

Инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.

10 стартмани

07.01.2020    13079    103    YPermitin    89    

Командный интерпретатор для 1С

Сервисные утилиты v8 1cv8.cf Абонемент ($m)

Инструмент для выполнения команд CMD / PowerShell из 1С.

2 стартмани

15.11.2019    11333    22    YPermitin    41    

Пакетная выгрузка / загрузка внешних отчетов и обработок

Прочие инструменты разработчика Менеджеры внешних отчетов v8 1cv8.cf Абонемент ($m)

Пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.

2 стартмани

04.11.2019    9034    31    YPermitin    22    

Обозреватель криптографии

Инструментарий разработчика Защита ПО v8 Абонемент ($m)

Отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.

2 стартмани

21.10.2019    9771    11    YPermitin    10    

Поиск некорректных дат средствами SQL

Поиск данных v8 1cv8.cf Бесплатно (free)

Ошибка "Дата ' **.**.**** ' не может быть записана в базу данных на MS SQL Server с нулевым смещением дат.

03.10.2019    2816    sutygin    8    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    11308    2    YPermitin    7    

Путеводитель по истории релизов

WEB v8 1cv8.cf Абонемент ($m)

Отчет по истории выпуска релизов и анализа информации по обновлениям.

5 стартмани

13.08.2019    13165    11    YPermitin    18    

Просмотр и анализ структуры базы данных (отчет на СКД)

Инструментарий разработчика v8 v8::СКД 1cv8.cf Абонемент ($m)

Отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.

5 стартмани

24.07.2019    20940    176    YPermitin    27    

Очистка и обновление индекса полнотекстового поиска (регламентное задание)

Производительность и оптимизация (HighLoad) v8 УНФ ДО БП3.0 УТ11 УХ ЗУП3.x Россия Абонемент ($m)

Обработка-регламентное задание позволяет в автоматическом режиме очищать и обновлять индекс полнотекстового поиска. Это необходимо делать для устранения проблем производительности на крупных базах. Подключаем в доп.обработках, задаем расписание выполнения на выходные и радуемся :)

2 стартмани

14.09.2018    20855    76    Kyrales    8    

Возвращение старого поиска в новых релизах Бухгалтерии предприятия 3.0

Работа с интерфейсом v8::БУ v8::УФ БП3.0 Бесплатно (free)

В последних релизах Бухгалтерии предприятия 3.0 почти во всех списках разработчики включили полнотекстовый поиск. Эта статья предназначена для тех, кто воспринимает "в штыки" такие нововведения, я расскажу, как вернуть старый поиск.

13.12.2016    21130    ardn    36    

Рекурсивный поиск каталога среди каталогов.

Поиск данных Универсальные функции v8 1cv8.cf Бесплатно (free)

Внимание особо умных. Предложенная процедура актуальна для конфигураций на платформе 8.1 и ниже. В них для функции НайтиФайлы не был реализован рекурсивный поиск в подкаталогах. Это указано в справке. Задача Найти путь к вложенному каталогу. Пример Каталог AST содержит каталоги A1, S1, T1 Каталог A1 содержит каталоги 0001, 0002, 0003 каталог S1 содержит каталоги 1001, 1002, 1003 Каталог Т1 содержит каталоги 2001, 2002, 2003 На входе функции КорневойКаталог = "D:\AST" КаталогПоиска = "1002" На выходе функции НайденныйПуть = "D:\AST\A1\1002" Уточнение - имена КаталогПоиска уникальны и не повторяются. Функция НайтиФайлы не помогает - она ищет их только в текущем каталоге.

19.09.2014    8690    betepon    5    

"Улучшение" поиска в динамических списках в 8.3.5

Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

Наверняка многие из вас читали публикацию 1С о доработке поиска в динамических списках - http://v8.1c.ru/o7/201401ls/index.htm. В первом приближении кажется, что все отлично и пользователи теперь смогут работать еще более эффективно. Но на практике ситуация очень далека от идеальной и имеет важные особенности.

23.07.2014    57360    Aleksey.Bochkov    38    

1С 8.2. Особенности поиска, выделение элементов

Поиск данных Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

По сравнению с 8.1, интерфейс 1С 8.2 в режиме управляемого приложения претерпел значительные изменения. Кроме внешнего вида, появились так же и новые "фишки". В частности, расширен механизм поиска.

24.05.2013    23323    megabax    10    

Пример алгоритма синхронизации справочников по GUID

Практика программирования Поиск данных v8 1cv8.cf Россия Бесплатно (free)

Порой при переводе систем с одной конфигурации на другую нужно часто переносить справочники из одних в другие. При этом сложно завязываться на код или наименование. Но! Можно завязаться на GUID элемента. 1С позволяет использовать один и тот же GUID в разных справочниках.

10.02.2012    18369    fixin    6    

Готовое решение для отслеживания конфликтов кадровых неявок в ЗУП и УПП

Управление персоналом (HRM) Поиск данных Тестирование и исправление Анализ учета Управление персоналом (HRM) v8 ЗУП2.5 ЗКБУ УПП1 Бесплатно (free)

В актуальной версии ЗУП 2.5 оперативный контроль кадровых неявок сводится к программной проверке : не начинается ли в эту же самую дату какая-то другая неявка? Многие пользователи считают, что этого явно недостаточно. Вашему вниманию предлагается готовое решение (в виде программного кода) для ЗУП и УПП, которое после проведения документа кадровой неявки информирует пользователя, какие конфликты кадровых неявок повлекло за собой проведение документа.

29.06.2011    15528    megatrend    8    

Восстановление битых ссылок в 1С

Практика программирования Поиск данных v8 1cv8.cf Россия Бесплатно (free)

Простая и относительно бескровная методика восстановления битых ссылок и ссылочной целостности.

19.01.2011    33585    romansun    15