Файл не обнаружен 'v8srvr://SERVER/Centr2014/Config... #724458

Пир выгрузке конфигурации в Конфигураторе выдает такую ошибку. Прав не хватает? Релиз 8.2.19

делаю проверку конфигурации. Главное, начинает сохранять, доходит до 12 % и выдает ошибку что временный файл по этому адресу отсутствует.

кэш?

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

dt-шки порядка 1,5 гб у меня нормально выгружаются- вгружаются. УПП.

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

Тут эта ошибка уже очень давно. А как узнать что за метаданное в файле 1d927a08-8256-4474-8981-68a6366cbff6

почти никак. если по метаданному создаются объекты бд, то в таблице params, записи  dbnames  хранится сопоставление метаданных и объектов бд. в вашем случае нужно удалить информацию из списка метаданных id записи хранится в config в записи root. как правило - e0666db2-45d6-49b4-a200-061c6ba7d569

Нашел в конфиг 1d927a08-8256-4474-8981-68a6366cbff6_dynupdate_f7100a33-2680-4220-9c65-827358bed983 вместо 1d927a08-8256-4474-8981-68a6366cbff6. Это, как я понимаю, пакость от динамического обновления. Просто переименовать можно? И сейчас мы это узнаем...

Уря!!!!

Или нет?

Уря! Или нет? Один я не понял?

Я таки исправил или только усугубил?

Сделал как в , выгрузил конфигурацию с CF, потом заново распаковал бэкап SQL, средствами 1С загрузил конфигурацию. В таблице стало две записи: 1d927a08-8256-4474-8981-68a6366cbff6_dynupdate_f7100a33-2680-4220-9c65-827358bed983 и 1d927a08-8256-4474-8981-68a6366cbff6 .

Далее запустил в sql dbcc checkdb Получил результат (извиняюсь за размеры):

Имеется 5769333 строк на 60738 страницах для объекта "_AccRgED387". CHECKDB обнаружил 0 ошибок размещения и 3713 ошибок согласованности в таблице "_AccRgED387" (идентификатор объекта 20963201).

CHECKDB обнаружил 0 ошибок размещения и 3714 ошибок согласованности в базе данных "Centr2014". repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (Centr2014). Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Сейчас попробую повторно запустить.