Приветствую!

Во время тестирования и исправления (конкретно при реструктуризации), когда процесс доходит до Регистра Бухгалтерии, выходит ошибка:

В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_VALUE_TYPE'
по причине:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_VALUE_TYPE'

Платформа: 8.1
Конфигурация: самописная
Тип базы: файловый, периферийный узел РИБ

Не помогло:
1. Поиск нулевых полей в регистре бухгалтерии через Tool_1CD.exe в полях ACCNTREG.
(точнее в поле ACCNTREGED было порядка 3500 строк 00000-0000-00, через hex-редактор нашел их, заменил на произвольные значения (1111), после chdbfl таблица стала без пустых записей).
2. Выгрузка *.dt и загрузка *.dt.

Изучение через поисковики навело на идею выгрузки и загрузки регистра бухгалтерии через XML.
Кто проделывал такое, подскажите пожалуйста, как лучше сделать?

Спасибо!
---
Поиск нулевых полей в регистре бухгалтерии через Tool_1CD.exe в полях ACCNTREG.
(точнее в поле ACCNTREGED было порядка 3500 строк 00000-0000-00, через hex-редактор нашел их, заменил на произвольные значения (1111), после chdbfl таблица стала без пустых записей).
NULL - это не нулевые значения полей. NULL - это специальная пометка у поля записи таблицы, если описание поля предусматривает это.
например, в описании таблицы в разделе полей
{"Fields",
{"ИмяПоля","ТипПоля",<ПризнакДопустимостиNULL>,<Длина>,<Точность>,"CI"},
у поля '_VALUE_TYPE' ПризнакДопустимостиNULL = 0, а 1с пытается туда записать NULL.
почему она пытается это сделать - это уже другой вопрос
---
Еще встретил предложение перенести на SQL. Еще не пробовал.

Да, и база работает нормально, обмен происходит. Ошибка выходит только в процессе ТиС (реструктуризации).
---
кэш чистили?
---
Поиск нулевых полей в регистре бухгалтерии через Tool_1CD.exe в полях ACCNTREG.
(точнее в поле ACCNTREGED было порядка 3500 строк 00000-0000-00, через hex-редактор нашел их, заменил на произвольные значения (1111), после chdbfl таблица стала без пустых записей).
NULL - это не нулевые значения полей. NULL - это специальная пометка у поля записи таблицы, если описание поля предусматривает это.
например, в описании таблицы в разделе полей
{"Fields",
{"ИмяПоля","ТипПоля",<ПризнакДопустимостиNULL>,<Длина>,<Точность>,"CI"},
у поля '_VALUE_TYPE' ПризнакДопустимостиNULL = 0, а 1с пытается туда записать NULL.
почему она пытается это сделать - это уже другой вопрос
---
andrewks, попробовал почистить - не помогло, то же самое выходит.
(4) по поводу NULL спасибо за объяснение,
просто аналогичная ошибка, когда там какое-нибудь другое поле типа FLD4656_TYPE - таким способом решается, т.е. через hex-редактор.
А тут видимо, не строка целая, а одно поле. Как его найти б? Выгрузка регистра в xml весит 500 мб. Не знаю как к ней обратиться даже, как прошерстить поле VALUE_DATA, к примеру.
---
в моей конфе БП2 поле '_VALUE_TYPE' нашлось в одной-единственной таблице _ACCRGED479
---
andrewks,
само поле я нашел, в таблице _ACCNTREGED1665, вот эту таблицу если выгружать - 500 мб как раз выходит XML файл (средствами Tool_1CD)

Однако! сейчас заметил, что в Tool_1CD.exe есть в верхней части 4 вида упорядочивания таблицы:
1. NONE
2. _ACCNTR1665_BYPERIOD_TRNRN
3. _ACCNTR1665_BYRECORDER_RNN
4. _ACCNTR1665_BYEXTDIM_RR
---
а для чего вообще запускаете ТиИ? какие-то проблемы с базой?
---
в моей базе это поле описано так: {"_VALUE_TYPE","B",0,1,0,"CS"},
т.е. двоичные данные размером один байт, без возможности записи NULL
---
Так вот, если сортировать данные по 4-му типу,
4. _ACCNTR1665_BYEXTDIM_RR
то получаем следующую картину

видны 1111 - которые являются хвостом моей деятельности в hex-редакторе!
Т.е., я не сказал предысторию, почему ТиИ потребовалось. Остановился обмен, и повреждены были 3 регистра накопления (нулевые строки в Tool_1CD). Их я исправил, и видимо, мимоходом задел регистр бухгалтерии...
Т.е. прежде выпадали ошибки записи NULL трижды в различные FLD4656_TYPE, FLD7854_TYPE и т.п., а за тем уже в
_VALUE_TYPE

Своими руками ошибку сделал получается...

Сейчас попробую найти эти 1111111
---
Разобрался с проблемой. О том как пришлось "извернуться" в картинках постараюсь в ближайшем времени расписать.

Прошу участников отписываться о том, в какие бубны еще стучать в подобных ситуациях.