Каков риск потери данных при добавлении реквизита типа «Строка» в 1С через расши

[Odineski]

В чем опасность добавления реквизта типа строка через расширение? Каков риск утери таких данных?

[Odin — Одинэсник]

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

## Когда данные сохраняются

Данные обычно сохраняются при следующих условиях:

— расширение остается установленным;
— реквизит не переименовывается;
— не меняется его тип;
— не удаляется сам реквизит;
— при обновлении расширения сохраняется тот же объект и тот же реквизит;
— основная конфигурация не удаляет объект, к которому добавлен реквизит;
— база данных корректно обновляется с резервной копией.

Например, в расширение добавлен реквизит:

1С (Код)

Документ.ЗаказКлиента.ДополнительныйКомментарий Тип: Строка, 500

1 2	Документ.ЗаказКлиента.ДополнительныйКомментарий Тип: Строка, 500

Если в следующей версии расширения этот же реквизит остается ДополнительныйКомментарий с тем же типом, значения должны сохраниться.

## Основные опасные ситуации

### 1. Удаление реквизита из расширения

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

После этого значения могут быть безвозвратно потеряны.

Особенно опасна последовательность:

1. в реквизит записали данные;
2. расширение удалили или отключили с удалением структуры данных;
3. базу обновили;
4. расширение установили снова.

После повторной установки это будет уже новый пустой реквизит. Старые значения автоматически не восстановятся.

Само отключение расширения не всегда означает немедленное удаление данных. Но рассчитывать на сохранность после удаления расширения или реструктуризации нельзя.

### 2. Переименование реквизита

Если вместо переименования средствами конфигуратора удалить старый реквизит и добавить новый, платформа может воспринять это как два разных реквизита:

1С (Код)

СтарыйКомментарий НовыйКомментарий

1 2	СтарыйКомментарий НовыйКомментарий

В результате старые данные останутся в старом поле либо будут удалены, а новый реквизит будет пустым.

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

Если нужно переименовать реквизит, безопаснее:

1. создать новую версию расширения;
2. временно сохранить старый реквизит;
3. перенести данные в новый реквизит обработкой;
4. проверить результат;
5. только потом удалять старый реквизит отдельным этапом.

### 3. Изменение типа реквизита

Например:

1С (Код)

Строка 100

1	Строка 100

изменяется на:

1С (Код)

Число 15.2

1	Число 15.2

или:

1С (Код)

Дата

1

Дата

Такое изменение может привести к:

— ошибке реструктуризации;
— невозможности преобразовать старые значения;
— частичной потере данных;
— необходимости ручной конвертации.

Надежный вариант при изменении типа:

1. добавить новый реквизит с новым типом;
2. перенести данные программно с проверкой;
3. проверить количество и содержимое перенесенных значений;
4. оставить старый реквизит на период контроля;
5. удалить старый реквизит только после резервного копирования.

### 4. Уменьшение длины строки

Увеличение длины строки обычно безопасно:

1С (Код)

Строка 100 -> Строка 500

1	Строка 100 -> Строка 500

Уменьшение длины опасно:

1С (Код)

Строка 500 -> Строка 100

1	Строка 500 -> Строка 100

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

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

### 5. Изменение основной конфигурации

Если реквизит добавлен к заимствованному объекту, а при обновлении основной конфигурации этот объект:

— удален;
— заменен другим объектом;
— изменен таким образом, что расширение больше не может его применить;
— перемещен или переименован с потерей связи,

то реквизит расширения может стать недоступным.

В этом случае возможны ошибки применения расширения и проблемы со структурой таблицы.

### 6. Несовместимость при отключении расширения

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

> Структура таблицы несовместима с текущими расширениями конфигурации

Это означает, что основная конфигурация и расширение по-разному ожидают структуру таблицы.

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

## Что происходит при обновлении самого расширения

Если новая версия расширения содержит тот же реквизит с тем же типом, данные должны сохраниться:

1С (Код)

ДополнительныйРеквизит Строка 200

1 2	ДополнительныйРеквизит Строка 200

Если длина увеличена, это обычно безопасно:

1С (Код)

Строка 200 -> Строка 500

1	Строка 200 -> Строка 500

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

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

1. сделать резервную копию;
2. проверить расширение на ошибки применения;
3. проверить, изменяет ли оно структуру данных;
4. установить расширение на копии базы;
5. проверить старые значения;
6. только потом устанавливать в рабочую базу.

## Важный отдельный риск: обмены

Добавленный через расширение реквизит не всегда автоматически участвует в стандартных обменах.

Например, реквизит добавлен в документ:

1С (Код)

Документ.РеализацияТоваровУслуг.КомментарийДляСклада

1	Документ.РеализацияТоваровУслуг.КомментарийДляСклада

Если документ передается через:

— РИБ;
— синхронизацию данных;
— EnterpriseData;
— обмен с другой базой;
— внешнюю интеграцию,

то новый реквизит может не передаваться, если обмен специально не доработан.

В итоге в одной базе значение будет заполнено, а в другой базе останется пустым. Это не потеря при хранении, но с точки зрения бизнеса данные могут «теряться» при обмене.

Для критичных реквизитов нужно отдельно проверить:

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

## Риск для строковых данных

Для типа «Строка» есть еще несколько особенностей:

— пустая строка и Неопределено могут обрабатываться по-разному;
— ограниченная длина может привести к ошибкам при записи;
— неограниченная строка может увеличивать объем хранения и влиять на производительность отчетов;
— перенос строк и специальные символы могут некорректно обрабатываться внешней системой;
— при выгрузке в XML, JSON или Excel могут действовать дополнительные ограничения;
— если строка используется в поиске и отборе, большие значения могут работать медленнее.

Это не означает высокий риск потери, но тип и длину строки нужно выбирать осознанно.

## Как безопасно добавить такой реквизит

Практический порядок:

1. Добавить реквизит в расширение.
2. Задать понятное стабильное имя, которое не придется менять.
3. Выбрать нужную длину строки с запасом.
4. Не использовать имя, которое может совпасть с будущим реквизитом основной конфигурации.
5. Проверить, что реквизит доступен в форме и записывается.
6. Сделать копию рабочей базы.
7. Установить расширение на копию.
8. Заполнить несколько тестовых значений.
9. Закрыть базу и снова открыть ее.
10. Проверить значения после обновления расширения.
11. Проверить отключение и повторное включение расширения на копии.
12. Отдельно проверить обмены, если база участвует в обмене.

## Если реквизит уже используется

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

— ссылку на объект;
— значение реквизита;
— дату выгрузки;
— идентификатор версии расширения.

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

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

## Оценка риска

Условно риск можно оценить так:

| Сценарий | Риск |
|—|—:|
| Добавили строковый реквизит и больше не меняете его | Низкий |
| Увеличили длину строки | Низкий |
| Обновили расширение без изменения имени и типа реквизита | Низкий |
| Отключили расширение без реструктуризации | Средний, данные могут быть недоступны |
| Удалили реквизит из расширения | Высокий |
| Переименовали через удаление и повторное добавление | Высокий |
| Изменили тип строки на другой тип | Высокий |
| Уменьшили длину строки | Средний или высокий |
| Не проверили обмены | Средний |
| Изменили расширение без резервной копии | Высокий |

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

[Автор]

Записи