При работе с государственными информационными системами, в частности с ВетИС (ФГИС «Меркурий»), пользователи и администраторы систем на базе «1С:Предприятие 8.3» часто сталкиваются со специфическими ошибками СУБД. Одна из самых распространенных и неприятных проблем возникает при попытке загрузить данные хозяйствующего субъекта или сопоставить предприятия.
Программа прерывает работу и выдает системное сообщение об ошибке следующего вида:
Не удалось выполнить загрузку по причине: {Справочник.ХозяйствующиеСубъектыВЕТИС.Форма.ДанныеКлассификатора.Форма(367)}: Ошибка при вызове метода контекста (Выполнить) ХозяйствующийСубъектОбъект.Предприятия.Загрузить(Запрос.Выполнить().Выгрузить()); по причине: {(4, 2)}: В запросе с предложениями РАЗЛИЧНЫЕ или ОБЪЕДИНИТЬ нельзя использовать поля неограниченной длины ИдентификаторыGLNПредприятий.GLN КАК GLN
В этой статье мы подробно разберем техническую природу этой ошибки, выясним, почему она возникает на уровне базы данных, и рассмотрим по шагам несколько надежных способов ее устранения.
Давайте проанализируем, почему СУБД (будь то Microsoft SQL Server, PostgreSQL или IBM DB2) выдает подобную ошибку при выполнении запроса платформы «1С:Предприятие».
Конструкции РАЗЛИЧНЫЕ (в терминах SQL — DISTINCT) и ОБЪЕДИНИТЬ (в SQL — UNION) требуют от СУБД выполнения операций сравнения и сортировки записей во временной памяти для исключения дубликатов. Однако СУБД физически не могут эффективно индексировать и сравнивать поля неограниченной длины (так называемые LOB-данные, Large Objects, которые в СУБД хранятся отдельно от основных страниц данных).
В системе 1С реквизит GLN (Global Location Number — международный код локации, состоящий строго из 13 цифр) в некоторых конфигурациях или интеграционных библиотеках (БЭД/БИГИС) ошибочно описывается во временных таблицах как строка неограниченной длины. Когда программный код интеграции ВетИС пытается выполнить запрос по временной таблице предприятий с ключевым словом РАЗЛИЧНЫЕ, СУБД аварийно завершает операцию, так как поле GLN имеет неограниченный тип.
Рассмотрим детально четыре практических метода исправления этой неполадки.
Поскольку данная проблема носит массовый характер и признана разработчиками фирмы «1С» как зарегистрированная ошибка интеграционных библиотек, самый простой способ — обновить конфигурацию до актуального релиза.
Если быстрое обновление всей информационной базы затруднено или невозможно по организационным причинам, выполним установку точечного исправления (патча):
После установки патча и перезапуска сеанса 1С проблема полностью исчезнет.
Если ваша конфигурация находится на поддержке с возможностью изменения (снята с замка) и вам требуется оперативно решить проблему прямо в коде, мы можем отредактировать проблемный запрос.
Для этого выполним следующие действия:
ХозяйствующиеСубъектыВЕТИС, развернем его ветку и откроем форму ДанныеКлассификатора.
ИдентификаторыGLNПредприятий.GLN КАК GLN
Заменим ее, принудительно приведя тип поля к строке ограниченной длины (для кода GLN достаточно 13 символов, но для надежности можно указать небольшой запас, например 100 символов):
ВЫРАЗИТЬ(ИдентификаторыGLNПредприятий.GLN КАК СТРОКА(100)) КАК GLN
После применения этой конструкции платформа «1С» передаст СУБД команду создания типизированного поля NVARCHAR(100). Сравнение и группировка по такому полю пройдут без каких-либо ошибок со стороны базы данных.
Если ваша конфигурация является полностью типовой и находится на поддержке без возможности редактирования, снимать ее с поддержки ради исправления одного запроса крайне нежелательно. В этом случае мы применим механизм расширений.
Выполним процедуру создания расширения по шагам:
ИсправлениеЗагрузкиВетИС) с назначением Исправление.ХозяйствующиеСубъектыВЕТИС, кликнем по нему правой кнопкой мыши и выберем команду Добавить в расширение. Также добавим в расширение форму ДанныеКлассификатора.ДанныеКлассификатора и перехватим процедуру, в которой формируется запрос (как правило, это процедура загрузки данных или заполнения табличной части), используя аннотацию &Вместо.ВЫРАЗИТЬ, как это было показано во втором способе.Альтернативный вариант в расширении — проверить ОпределяемыйТип.GLN. Если этот тип присутствует в вашей конфигурации, добавьте его в расширение и явно задайте ему тип Строка с фиксированной длиной 13, убрав галочку неограниченной длины.
Иногда корни проблемы лежат не только в коде, но и в самих данных, когда в поле GLN у контрагентов или предприятий по ошибке записывается невалидный текст огромного объема (например, комментарии пользователей, адреса или многострочные примечания).
Для того чтобы проанализировать базу данных на предмет некорректных значений, мы можем запустить простой запрос в консоли запросов или создать внешнюю обработку:
ВЫБРАТЬ
Контрагенты.Ссылка КАК Контрагент,
Контрагенты.GLN КАК НекорректныйGLN,
ДЛИНАСТРОКИ(Контрагенты.GLN) КАК ДлинаПоля
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
ДЛИНАСТРОКИ(Контрагенты.GLN) > 13
Проанализируем результаты выполнения данного запроса. Если мы обнаружим элементы, у которых длина реквизита превышает стандартные 13 символов, эти записи необходимо очистить либо исправить вручную. Запись некорректных длинных строк в реквизит может провоцировать сбои при выгрузке и сопоставлении с классификатором ВетИС.
Мы надеемся, что эти подробные инструкции помогут вам быстро локализовать проблему и восстановить штатный обмен данными с ФГИС «Меркурий»!