v7: Ошибка SDBL при тестированиии и исправлении базы 1С 8.1 #324895

Запускаю тестирование и исправление файловой базы. Параметры тестирования и исправления - создавать объекты Тестирование заканчивается ошибкой: "Ошибка SDBL Поле Fld4382 таблицы DocumentJournal3294 не может принимать значение NULL (pos=178)" В момент появления ошибки в строке состояния написано: "Проверка Логической целостности  Документы Реализация товаров и услуг." Кто-ть сталкивался с подобной проблемой? Что можно предпринять в данной ситуации?

Подскажите как с этим жить )

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

Данная база является файловой. Так что перегружать нечего. Судя по названию таблицы DocumentJournal3294  - здесь храняться ссылки на документы. Могу предположить, что реализация товаров и услуг. То есть при тестировании он пытается восстановить документ реализация, и записывает в одно из полей этого документа, которое считается не пустым пустую ссылку, так как не может восстановить значение данного поля. Как вам такая теория? Вопрос как бы вычислить ссылку на этот документ (уже не существующий в базе) и "почистить" данные, чтобы позволить тестированию завершить свое благое дело?

CHDBFL

CHDBFL говорит, что ошибок не обнаружено. Что можно еще попробовать?

Я тут пока баловался с базой. Свернул данные по начала 2007 года. Удалил все помеченные на удаление объекты, на которые нет ссылок. Тестирование и исправление упорно вылетает с той же ошибкой, только номер pos немного сместился. Я почел дальше, загрузил базу на SQL сервер. При загрузке на ряд таблиц получил такое сообщение: "Таблица '_Document150' содержит значения типа Дата, которые не могут быть записаны в MS SQL Server с нулевым смещением дат" Правда тестирование и на sql базе завершается той же ошибкой. Видел при создании базы на Сервере 1С предприятия есть возможность указывать смещение дат, но как и на что это влияет - не знаю. Подкажите кто в курсе.

Выгрузи в файл и загрузи наново.

Процесс выгрузки загрузки в любых вариациях (из, в, SQL, файловый вариант) не помогает. По поводу смещения дат нашел вот здесь такой текст: "параметр «смещение дат в годах» может иметь одно из двухзначений: 0 или 2000. Данный параметр определяет число лет, которое будет прибавляться к датам при их сохранении в базе данных Microsoft SQL Server и вычитаться при их извлечении. Наличие данного параметра определяется особенностями хранения дат в Microsoft SQL Server 2000. Тип DATETIME, используемый в Microsoft SQL Server 2000, позволяет хранить даты в диапазоне с 1 января 1753 года по 31 декабря 9999 года. И если при работе с информационной базой может возникнуть необходимость хранения дат предшествующих нижней границе данного диапазона, то в качестве значения параметра следует выбрать 2000. Если же такие даты встречаться не будут, то в качестве смещения дат можно выбрать 0. После создания информационной базы значение данного параметра не может быть изменено; " Кругозор расширил, но беде пока не помог.

В общем с тестированием и исправлением вроде разобрался. Поле Fld4382 таблицы DocumentJournal3294 - это графа организация журнал операций (в моей базе). Журналы, как я понимаю, это таблицы, отражающие имеющиеся в базе документы в удобном для пользователя виде (альтернатива списку документов), поэтому для сохранности данных не важно, что именно отражается в этих журналах. Поэтому я удалил графу из журнала и запустил тестирование, которое опять остановилось с ошибкой, но другой: "Поле Fld4392 таблицы DocumentJournal3297 не может принимать значение NULL (pos=397)" -- это графа организация  журнала РасчетныеДокументыБанк. Я взял и просто удалил все журналы в конфигурации (мало ли где еще есть ошибки). Запустил тестирование и исправление, которое завершилось успешно. Я тестировал центральную базу (SQL), но есть еще и периферийная (файловая). Весь сыр-бор начался из-за того, что в один прекрасный момент центральная база при получении файла обмена из периферийной выдала такую вот ошибку: "Попытка вставки неуникального значения в уникальный индекс: Microsoft OLE DB Provider for SQL Server: Невозможно вставить повторяющуюся ключевую строку в объект "dbo._AccTtl23575" с уникальным индексом "_AccTt23575_ByPeriod_TRRRRR". HRESULT=80040E2F, SQLSrvr: Error state=1, Severity=E, native=2601, line=1" После тестирования обеих баз, ошибка осталась. AccTt23575 - это таблица РегистрБухгалтерии.Хозрасчетный ИтогиПоСчетамССубконто2. Вроде как содержит итоги по регистру. Я пробовал пересчитывать итоги, ошибка остается (понятно, что каждый раз файл обмена я фомирую заново). Получается, что в базе есть данные, по которым итоги расчитываются некорректно. Но ведь я провел тестирование и исправление, как такое может быть. Замечание1: В посте я описал, что при переводе периферийной базы на sql получил сообщения от MS SQL сервера, что данные ряда таблиц не были загружены в sql, так как sql не понимает хранящиеся там даты. Замечание2: Я перевел центарльную базу из sql  в файловый вариант. В нее файл обмена с периферийной базой (выгрузка из ее файловой версии) был успешно принят. Но вернуть центральную базу на sql не удалось. При загрузке выдана ошибка: "Операция CREATE UNIQUE INDEX прервана так как обнаружен повторяющийся ключ" Его значение 1 янв 1753 года 12:00 AM. У кого-ть есть варианты, что делать? PS: Научите, пожалуйста, добавлять ссылки на ветки форума и ссылки на посты этой ветки.

Разобрался. Если кому интересно с ошибкой: HRESULT=80040E2F, SQLSrvr: Error state=1, Severity=E, native=2601, line=1" при загрузке данных из филиальной базы (РИБ). В центарльной базе пользователь расширил аналитику одного счета (добавил второе субконто). Это изменение не попало в филиалы (пока не понятно почему, так как план счетов входит в состав плана обмена). Когда в филиале инициировали перегрузку в центральную базу проводки с этим счетом и выгрузили, то, при загрузке в центральную базу в таблице проводок появляется проводка со значением второго субконто NULL. И когда 1С честно расчитывает итоги по второму субконту, то он добавляет запись с итогами по незаполненному второму субконто и NULL, которые выпадают на один период регистрации итогов. Вот.