Рано или поздно каждый разработчик или администратор баз данных «1С:Предприятие» сталкивается с необъяснимыми на первый взгляд сбоями системы. Представьте стандартную рабочую ситуацию: пользователь открывает документ, пытается добавить в табличную часть номенклатуру, вводит в поле ввода ее артикул (например, 46E462), и в этот момент программа аварийно завершает работу с критической ошибкой:
«Ошибка SDBL. Длина числовой константы превышает максимально допустимое значение (pos=...)»
При этом, если выбрать ту же самую позицию интерактивно через форму списка справочника или через обработку подбора, система работает абсолютно корректно. Ошибка также бесследно исчезает, если изменить артикул на аналогичный, но без латинской буквы «E» (например, заменить ее на русскую «Е» или добавить в конец любой символ). В рамках этой статьи мы детально проанализируем физику этого процесса, выясним причины такого поведения платформы и разберем по шагам все возможные методы решения данной проблемы.
Для того чтобы понять природу этой ошибки, нам необходимо заглянуть под капот платформы «1С:Предприятие». Аббревиатура SDBL расшифровывается как Simple DataBase Layer — это собственный внутренний слой абстракции СУБД, разработанный фирмой «1С». SDBL выступает посредником между объектной моделью запросов «1С» и языком SQL конкретной используемой базы данных (будь то MS SQL Server, PostgreSQL, IBM DB2 или Oracle Database). SDBL транслирует высокоуровневые запросы платформы в оптимизированные низкоуровневые SQL-инструкции.
Когда пользователь начинает вводить текст в поле ввода («Номенклатура»), в системе автоматически инициируется механизм «Ввод по строке». В этот момент платформа пытается найти совпадение по всем реквизитам справочника, для которых в конфигураторе взведен флаг быстрого поиска (обычно это Код, Наименование и Артикул).
Проанализируем, что происходит, когда система обрабатывает поисковую строку 46E462:
Код) имеет числовой тип данных (Число).E (в латинской раскладке клавиатуры) во всех современных языках программирования и стандартах баз данных зарезервирован как математический разделитель экспоненты (научный/экспоненциальный формат записи чисел).46E462 не как текстовую строку, а как математическое выражение вида: 46 * 10 в степени 462.Numeric или Decimal в реляционных базах данных обычно ограничена 38 знаками.Эта проблема является официально признанным багом платформы «1С:Предприятие» и зарегистрирована в официальной базе ошибок под номером 20006543 (внутренний код SW706073) с формулировкой «Поиск по строке для числовых полей».
Рассмотрим подробнее все существующие методы решения этой проблемы — от простых административных до профессиональных программных архитектурных подходов.
Это самый быстрый и безопасный способ исправления ошибки, не требующий изменения структуры хранения данных в базе. Если для поиска номенклатуры по строке вам не требуется использовать числовой код, лучшим решением будет просто исключить его из списка индексируемых полей быстрого поиска.
Выполним это решение по шагам:
Номенклатура (или любой другой справочник, на котором воспроизводится ошибка) и откройте его свойства.Код (имеющий тип Число), снимите с него флажок или удалите его из списка. Оставьте только текстовые поля (например, Наименование, Артикул).После выполнения этих действий платформа перестанет транслировать строковый ввод пользователя в числовые SQL-фильтры для данного справочника, и ошибка SDBL больше никогда не побеспокоит ваших пользователей.
В типовых конфигурациях фирмы «1С» (таких как «Управление торговлей», «ERP Управление предприятием», «Бухгалтерия предприятия» и др.) стандартный реквизит Код для большинства справочников по умолчанию имеет тип Строка. Это сделано намеренно, чтобы избежать коллизий при автоматической нумерации, интеграции с внешними системами и для предотвращения подобных ошибок парсинга данных.
Если вы работаете в самописной или сильно измененной конфигурации, где код справочника имеет тип Число, мы настоятельно рекомендуем перевести его в тип Строка. Разберем особенности этого процесса:
Номенклатура, перейдите на вкладку «Данные» и измените тип реквизита Код с «Число» на «Строка». Установите необходимую длину кода (например, 11 или 20 символов).Поскольку теперь реквизит Код стал текстовым, SDBL при вводе строки 46E462 будет сравнивать текстовые строки, не пытаясь выполнять математические преобразования и вычисления экспонент.
В современных версиях платформы 1С:Предприятие 8.3 существует мощный механизм управления интерактивным поиском на уровне кода. Мы можем программно перехватить текст, который вводит пользователь, проверить его на наличие опасных паттернов (таких как экспоненциальная запись чисел) и скорректировать параметры поиска до того, как запрос уйдет в SDBL.
Для реализации этого метода проанализируем и внедрим следующий код в модуль менеджера справочника Номенклатура. Разберем этот пример по шагам:
Номенклатура.ОбработкаПолученияДанныхВыбора:
Процедура ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
СтрокаПоиска = СокрЛП(Параметры.СтрокаПоиска);
// Проверим, содержит ли строка поиска латинскую букву E в окружении цифр,
// что может спровоцировать ошибку парсинга экспоненты в SDBL.
Если ЭтоОпаснаяЭкспонента(СтрокаПоиска) Тогда
// Отменяем стандартную обработку поиска платформой
СтандартнаяОбработка = Ложь;
// Формируем собственный список выбора
ДанныеВыбора = Новый СписокЗначений;
// Выполняем безопасный запрос к базе данных, принудительно типизируя поиск только по текстовым полям
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 30
| Номенклатура.Ссылка КАК Ссылка,
| Номенклатура.Представление КАК Представление
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
|ГДЕ
| (Номенклатура.Артикул ПОДОБНО &СтрокаПоиска
| ИЛИ Номенклатура.Наименование ПОДОБНО &СтрокаПоиска)";
Запрос.УстановитьПараметр("СтрокаПоиска", "%" + СтрокаПоиска + "%");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ДанныеВыбора.Добавить(Выборка.Ссылка, Выборка.Представление);
Если ДанныеВыбора.Количество() >= 30 Тогда
Прервать;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Функция ЭтоОпаснаяЭкспонента(Знач ПроверяемаяСтрока) Экспорт
// Очистим строку от пробелов
ПроверяемаяСтрока = ВРег(СтрЗаменить(ПроверяемаяСтрока, " ", ""));
ДлинаСтроки = СтрДлина(ПроверяемаяСтрока);
Если ДлинаСтроки < 3 Тогда
Возврат Ложь;
КонецЕсли;
// Проверяем наличие латинской 'E' в строке
ПозицияЕ = Найти(ПроверяемаяСтрока, "E");
Если ПозицияЕ = 0 Тогда
Возврат Ложь;
КонецЕсли;
// Проверим, что символ 'E' не является первым или последним
Если ПозицияЕ = 1 Или ПозицияЕ = ДлинаСтроки Тогда
Возврат Ложь;
КонецЕсли;
// Проверим, что до и после 'E' находятся только цифры
ЧастьДо = Лев(ПроверяемаяСтрока, ПозицияЕ - 1);
ЧастьПосле = Сред(ПроверяемаяСтрока, ПозицияЕ + 1);
Возврат (ЭтоТолькоЦифры(ЧастьДо) И ЭтоТолькоЦифры(ЧастьПосле));
КонецФункции
Функция ЭтоТолькоЦифры(Знач СтрокаПроверки)
Для Индекс = 1 По СтрДлина(СтрокаПроверки) Цикл
Символ = Сред(СтрокаПроверки, Индекс, 1);
Если Найти("0123456789", Символ) = 0 Тогда
Возврат Ложь;
КонецЕсли;
КонецЦикла;
Возврат Истина;
КонецФункции
Этот алгоритм перехватывает ввод пользователя, анализирует строку на наличие паттерна экспоненциального числа с помощью вспомогательных функций и, в случае угрозы падения системы, перенаправляет поиск в безопасное русло — строит плоский текстовый SQL-запрос только по полям Артикул и Наименование, полностью минуя поиск по числовому реквизиту Код.
Если вы не хотите вносить изменения в структуру базы данных или программный код конфигурации, можно решить проблему на уровне административного регламента ведения нормативно-справочной информации (НСИ):
Мы подробно проанализировали причину возникновения критического сбоя SDBL при вводе артикулов с буквой «E». Эта ошибка — классический пример того, как пересекаются особенности реализации платформы 1С, СУБД и математических стандартов компьютерной графики записи чисел. Наиболее надежным и архитектурно правильным решением проблемы является перевод реквизита Код в строковый тип данных (Способ 2) либо программная фильтрация ввода через событие ОбработкаПолученияДанныхВыбора (Способ 3).