Что будет, если уменьшить длину строки у реквизита документа в 1С: последствия и правильный порядок действий

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

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

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

Что происходит с данными при уменьшении длины строки?

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

С технической стороны на уровне СУБД (будь то MS SQL Server, PostgreSQL, IBM DB2 или Oracle) происходит явное преобразование типов данных. Платформа 1С отправляет СУБД команду, аналогичную следующей:

CAST(ИмяПоля AS VARCHAR(НоваяДлина))

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

Как устроен процесс реструктуризации «под капотом» СУБД

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

  1. Создание временной таблицы: СУБД создает точную копию таблицы целевого документа, но уже с измененной (уменьшенной) структурой колонки реквизита.
  2. Копирование и усечение: Данные из исходной таблицы последовательно переносятся во временную таблицу. Именно в этот момент СУБД выполняет команду CAST, отсекая «лишние» символы у длинных строк.
  3. Замена таблиц: Старая таблица удаляется (или переименовывается во временную для последующего удаления), а новая таблица получает имя оригинальной.
  4. Перестроение индексов: Если по данному реквизиту был построен индекс или он участвовал в критериях отбора, СУБД полностью перестраивает эти индексы с нуля.

Важный нюанс: требования к ресурсам. Поскольку происходит копирование данных, СУБД требуется огромный объем свободного дискового пространства. На сервере должно быть свободно как минимум столько же места, сколько весит таблица реструктуризируемого документа. Кроме того, транзакция по перезаписи миллионов строк вызывает лавинообразный рост лога транзакций (например, файла .ldf в MS SQL Server). Если на диске закончится место, транзакция откатится, а база данных может остаться в заблокированном или аварийном состоянии.

Различия между ограниченными и неограниченными строками

В платформе «1С:Предприятие» строковые реквизиты могут иметь фиксированную длину (ограниченные строки) или быть неограниченной длины. Это кардинально влияет на их физическое хранение:

Если вы решите изменить тип реквизита с неограниченной длины на ограниченную длину (например, сделать комментарий длиной 200 символов вместо неограниченного), платформа будет вынуждена переносить данные из вспомогательной таблицы обратно в основную с попутным усечением. Такая реструктуризация выполняется значительно дольше и требует повышенного внимания.

Пошаговый алгоритм безопасного уменьшения длины строки

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

Шаг 1. Предварительный анализ данных

Прежде чем вносить изменения в конфигурацию, выясним, сколько документов реально пострадает от усечения данных. Для этого запустим консоль запросов в режиме «1С:Предприятие» и выполним следующий запрос. В качестве примера возьмем документ «Поступление товаров и услуг» и реквизит «Комментарий», длину которого мы хотим уменьшить до 50 символов:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Ссылка КАК ДокументСсылка,
    |   Комментарий КАК ТекстКомментария,
    |   ДЛИНА_СТРОКИ(Комментарий) КАК ТекущаяДлина
    |ИЗ
    |   Документ.ПоступлениеТоваровУслуг КАК ПоступлениеТоваровУслуг
    |ГДЕ
    |   ДЛИНА_СТРОКИ(Комментарий) > &НоваяМаксимальнаяДлина";

Запрос.УстановитьПараметр("НоваяМаксимальнаяДлина", 50);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();

Пока Выборка.Следующий() Цикл
    Сообщить("Документ: " + Выборка.ДокументСсылка + " будет обрезан. Длина: " + Выборка.ТекущаяДлина);
КонецЦикла;

Этот простой запрос покажет точный список документов, текстовые данные в которых превышают планируемый лимит. Проанализировав этот список, вы сможете оценить критичность потерь.

Шаг 2. Предварительная программная обработка строк (Опционально)

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


ВыборкаДокументов = Документы.ПоступлениеТоваровУслуг.Выбрать();
Пока ВыборкаДокументов.Следующий() Цикл
    ОбъектДокумента = ВыборкаДокументов.ПолучитьОбъект();
    ОчищенныйТекст = СокрЛП(ОбъектДокумента.Комментарий);
    
    // Если после удаления концевых пробелов текст изменился, перезапишем документ
    Если ОчищенныйТекст <> ОбъектДокумента.Комментарий Тогда
        ОбъектДокумента.Комментарий = ОчищенныйТекст;
        ОбъектДокумента.Записать(РежимЗаписиДокумента.Запись);
    КонецЕсли;
КонецЦикла;

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

Шаг 3. Создание резервной копии

Никогда не выполняйте реструктуризацию без резервной копии! Создайте резервную копию базы данных средствами СУБД (файлы .bak для MS SQL) или выгрузите информационную базу в файл .dt, если работаете в файловом режиме.

Шаг 4. Монопольный режим

Изменение структуры таблиц базы данных невозможно выполнить с помощью механизма динамического обновления (так называемого «горячего» обновления). Вам потребуется завершить сеансы всех активных пользователей системы. Убедитесь через консоль администрирования кластера 1С, что в базе нет активных соединений и фоновых заданий.

Шаг 5. Применение изменений в Конфигураторе

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

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

← На главную