1с нарушена целостность структуры конфигурации

Обновлено: 01.07.2024

Исправление ошибки "Нарушена целостность структуры конфигурации"

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

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

При этом в повседневной жизни данная ошибка никак себя не проявляла, и утилита chdbfl также не нашла в базе каких-либо ошибок. Тем не менее база оказалась серьезно повреждена и любые попытки спасти ситуацию малой кровью: выгрузить данные в узел РИБ или посредством выгрузки-загрузки через XML приводили к ошибкам.

"А как-же резервные копии?" - спросит иной читатель. Резервные копии содержали точно такую же ошибку, так как она не препятствует выгрузке в DT файл и, тем более, архивированию непосредственно файла базы. Можно сказать, что клиент столкнулся с распространенной ошибкой начинающих администраторов, когда резервные копии создаются, но не проверяются.

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

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

Что предлагала нам вышеуказанная статья? Заменить кеш поврежденной базы на кеш от исправной, того же самого релиза, разумное зерно в этом есть и в ряде случаев такой подход увенчается успехом, но не в этот раз. Почему?

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

Не для кого ни секрет, что многие данные в информационной базе не меняются в течении длительного времени и поэтому нет необходимости каждый раз их запрашивать из БД, а можно поместить в локальный кеш и брать оттуда. Кеш делится на пользовательский, где хранятся данные, с которыми работает пользователь и кеш конфигурации, где сохраняются программные модули и данные о конфигурации. Первый располагается в перемещаемой части профиля пользователя %USERPROFILE% \AppData\Roaming\1C, а второй в его локальной части %USERPROFILE%\AppData\Local\1C.

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

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

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

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

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

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

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

Исходные данные: 1C Предприятие 8.3, клиент-серверная база, MS SQL 2012, резервное копирование настроено средствами MS SQL, бэкапы создаются 1 раз в сутки, ночью.

Конфигурация модифицированная и над ней ведется активная работа, поэтому у меня была вторая серверная база, в которой и велась разработка, плюс имелись в наличии выгрузки в dt из обеих баз на предыдущий день. В качестве имени рабочей базы в статье будет применено "MyBase", в качестве имени резервной серверной базы "MyTestBase"/

В моем случае таблица базы ConfigSave была пустой, как и в описанных материалах, а в таблицах Config и Params присутствовали строки со значением "DynamicallyUpdated" в поле FileName

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

Delete From [MyBase].[dbo].[Config]
WHERE [FileName] LIKE 'DynamicallyUpdated'
и
Delete From [MyBase].[dbo].[Params]
WHERE [FileName] LIKE 'DynamicallyUpdated'

4. В резвервную базу средствами конфигуратора загружена последняя выгрузка .dt из рабочей базы (вечер предыдущего дня) и поверх загружена последняя рабочая конфигурация текущего дня из имеющегося файла .cf (вся история изменений конфигурации хранится в отдельных файлах с номерами версий)

5. В диспетчере задач пришлось отключить повисшие процессы 1с8

6. Остановлена служба сервера 1с

7. Очищен кэш 1С

В моем случае это было переименование папок C:\Users\Администратор\AppData\Local\1C\1сv8

8. Запущена служба сервера

9. После чистки кэша окно со списком баз при запуске 1С пустое, поэтому добавляем существующую рабочую серверную базу

10. Открылся конфигуратор. Делаем на всякий случай выгрузку в .dt рабочей базы в текущем "сломанном" состоянии и закрываю конфигуратор

11. Запускаем SQL Server Management Studio и запросом очищаем в рабочей базе таблицу Config и перезаписываем ее содержимым аналогичной талицы из резервной базы:

Delete From [MyBase].[dbo].[Config]

INSERT INTO [MyBase].[dbo].[Config] SELECT * FROM [MyTestBase].[dbo].[Config]

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

Delete From [MyBase].[dbo].[Params]

INSERT INTO [MyBase].[dbo].[Params] SELECT * FROM [MyTestBase].[dbo].[Params]

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

Обычно ошибка возникает когда в процессе сохранения конфигурации, был сбой. В результате Конфигурация сохранилась не корректно.
1. Попробовать проверить через тестирование и исправление или ChDBFl.exe
2. Посмотрите следующие варианты решения проблемы:

У меня возникла похожая ситуация, но на 8.1. При динамическом обновлении конфигурации видимо произошел сбой, после чего попытка выгрузить и как Основную конфу и конфу БД при дальнейшей попытке загрузить файл в локальную базу вываливалось "нарушена целостность структуры конфигурации". Но БД работоспособна. Ни тестирование и исправление ни ChDBFl.exe ничего не дали.

Если не поможет могу посоветовать вариант к которому хотел прибегнуть сам:
1. найти ближайший релиз конфигурации, загрузить его в чистую БД (восстанавливаемую).
2. создать совершенно чистую БД (промежуточную)
3. открыть конфигуратор испорченной БД.
4. скопипастить модули и объекты, в которых происходили изменения с последнего релиза (в моем случае намного проще, поскольку изменения происходили только в модулях и формах, структура данных осталась прежней а все изменения документируются постерами) из испорченной БД в промежуточную.
5. Выгрузить промежуточную конфигурацию.
6. Объеденить ее с восстанавливаемой БД.
7. Выгрузить восстанавливаемую конфигурацию в файл.
8. Загрузить в испорченную БД конфигурацию из восстанавливаемой.

Мой вариант решения - заменить конфигурацию поставщика нашей базы.
Последовательность действий следующая:
1. Удалить конфигурацию поставщика путём снятия с поддержки(Конфигурация->Поддержка->Настройка поддержки->Снять с поддержки)
2. Создаем файл поставки конфигурации(Конфигурация->Поставка конфигурации->Создать файлы поставки и обновления конфигурации). Файл при этом назовем work файл поставки.cf
3. Объединяем нашу конфигурацию с только что созданным файлом поставки(Конфигурация->Сравнить, объединить с конфигурацией из файла). При этом появится предложение вновь поставить конфигурацию на поддержку
В появившемся окне сравнения конфигураций нажимаем "Выполнить",
4. Обновляем конфигурацию базы данных(Конфигурация->Обновить конфигурацию базы данных).
Поидее, выполняя данные действия, мы реструктуризовали конфигурацию поставщика.
Теперь можно попробовать обновить нашу конфигурацию до следующей версии в обычном режиме.

Читайте также: