Как в прямом SQL-запросе записать значение Истина в поле типа Булево таблицы 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При выполнении прямых запросов к базе данных 1С:Предприятия разработчики нередко сталкиваются с необходимостью изменить или вставить логическое значение (тип Булево). В СУБД Microsoft SQL Server платформа 1С хранит простые логические реквизиты в виде колонок с типом binary(1). Разберем, какие именно литералы необходимо передавать в SQL-запросах, как устроено хранение булевых данных в различных СУБД и на какие важные системные нюансы следует обратить внимание.

Шестнадцатеричное представление логических значений в MS SQL Server

Посмотрим на структуру данных Microsoft SQL Server. Поле типа binary(1) представляет собой бинарную строку фиксированной длины в один байт. Для корректной записи логических констант в прямых SQL-выражениях (операторы INSERT или UPDATE) используются шестнадцатеричные литералы:

  1. Истина (True) — записывается как 0x01.
  2. Ложь (False) — записывается как 0x00.

Проанализируем пример выполнения прямого обновления поля в таблице регистра или справочника:


UPDATE _InfoRg1234
SET _Fld5678 = 0x01
WHERE _Period = '2025-01-01'

Обратите внимание: использование обычных целочисленных литералов 1 или 0 без явного приведения типов может приводить к ошибкам несовместимости типов или неявным преобразованиям со стороны СУБД. Поэтому безопасным и стандартизированным вариантом для MS SQL является именно шестнадцатеричный литерал 0x01.

Особенности хранения Булево в других СУБД

Рассмотрим подробнее, как платформа 1С организует хранение логического типа в зависимости от используемого движка баз данных:

  1. PostgreSQL: Платформа создает колонки с нативным типом данных boolean. Соответственно, в прямых запросах используются стандартные значения TRUE (или 't') для истины и FALSE (или 'f') для лжи.
  2. Oracle Database: Логические реквизиты хранятся в полях с типом RAW(1), где для истины также применяется значение '01'.
  3. IBM DB2: Для хранения типа Булево применяется тип данных char(1) for bit data.

Исключение: инверсия системного поля иерархии _Folder

Выясним важную деталь, на которую следует обратить внимание при работе со структурой таблиц 1С. В иерархических справочниках системный реквизит ЭтоГруппа в базе данных хранится в поле _Folder. Логика хранения признака группы инвертирована относительно привычного понимания:

  1. 0x00 — запись является группой (папкой) справочника.
  2. 0x01 — запись является обычным элементом справочника.

Таким образом, условие ЭтоГруппа = Истина на уровне SQL-таблицы MS SQL Server соответствует условию _Folder = 0x00.

Хранение типа Булево в реквизитах составного типа

Если реквизит объекта или ресурс регистра имеет составной тип данных (в который включен тип Булево), платформа делит хранение значения на несколько физических колонок в СУБД:

  1. Колонка типа данных с суффиксом _TYPE (тип binary(1)) — хранит байт-идентификатор типа. Для типа Булево сюда записывается значение 0x01.
  2. Колонка логического значения с суффиксом _L (тип binary(1) в MS SQL или boolean в PostgreSQL) — хранит само значение (0x01 или 0x00).

При прямой модификации составного реквизита необходимо обновлять обе колонки синхронно, иначе платформа не сможет корректно прочитать тип и значение поля.

Штатные альтернативы и риски прямой модификации SQL

Разберем риски, связанные с прямой записью данных в обход платформы 1С:

  1. Кэширование данных: Кластер серверов 1С кэширует считанные записи в оперативной памяти. Изменения, внесенные напрямую в СУБД, не сбрасывают кэш платформы, из-за чего пользователи могут видеть старые данные до перезапуска рабочих процессов или очистки кэша.
  2. Нарушение бизнес-логики: Прямая запись не вызывает платформенные события ПередЗаписью и ПриЗаписи, а также не запускает подписки на события.
  3. Целостность итогов: Прямая модификация таблиц движений регистров не обновляет автоматически агрегаты и таблицы итогов.

Для определения точных имен таблиц и полей в коде 1С рекомендуется использовать штатный метод платформы ПолучитьСтруктуруХраненияБазыДанных(). Для массовой и быстрой записи данных без нарушения целостности базы безопаснее использовать штатный объект РегистрСведенийНаборЗаписей с записью в рамках одной транзакции.

← На главную