На рабочей базе сделал динамическое обновление.
Сравнение/объединение конфигурации. И динамическое обновление рабочей конфигурации.
  Немного ошибся.
  Часть пользователей еще работает на старой конфигурации. Можно ли откатиться на конфигурацию пользователей.

так уже кэш слетел, так что хуже точно не будет.

делай еще одно динамическое обновление со старой конфигурацией

Да нет не осталось изменений. Но у пользователей они пока есть

Нет старой конфигурации. Только на утро

нельзя, динамическое обновление уже заменило рабочую конфу...

сейчас можно только достать бекап из него CF и его накатить обратно

(3) исправляй косяк без отката

А если сделать РИБ под юзером кто еще на стараой?

Это как достать бекап из CF

ЦФ из бэкап

А у пользователей в кеше нигде нет конфигурации?

(10) У них есть только некоторые части конфигурации в кэше. Полной версии у них нет.

(10) у пользователя нет целой конфигурации, есть кеш отдельных клиентских форм/и подобного.

серверный код к клиенту не попадает по определению

А на сервере нет ли где в кеше?

Забудь про кэши. Там конфигурация если и хранится, то хранится совсем в другом виде.

(13) возьми из вчерашней копии, это вы 10000 раз проще, чем где-то в темпах ты найдешь непонятный кусок.

(13) есть, но ты конфу не соберешь...

уверяю тебя - проще достать из утреннего бекапа, или из хранилища (ведь профи даже для одиночной разработки их ведут)

Пока бекап восстанавливается. Ишу. 1с делает 100 Gb кеша

Единственно что, где ещё как-то можно подёргаться, так это только если база SQL - когда изменения ещё в SaveConfig лежат.

База SQL

Может можно SQL откатить?

я-бы у себя поступил так

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

для 20 гиговой базы это все примерно 15..20 минут

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

(19) Тогда можно потрепыхаться. Можно попробовать таблицу Config в чистую базу скопировать и там удалить последние записи по дате динамического обновления. Сам так не пробовал, но однажды я так "откатывал" неудачное завершение типового обновления.

(22) не будет, он заново перечитается...

там хранится последняя контрольная сумма которая была в этом контксте, в данном случае будет на 100% перечитана конфа

(24) Научись уже внимательно читать

Я бы просто развернул копию базы из бекапов боевой базы на момент до дин. обновления, зашел в конфигуратор в этой новой копии, выгрузил CF, и накатил бы снова динамически. Никто бы не заметил даже ничего.

(25) я читать умею.

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

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

и для 20ти гиговой базы это вроде 5 минут от силы..

(27) Хз зачем ты это все написал

(29) Эээ... Попробовать, не открывая конфигуратор, достать ту, что в кэше лежит, - теоретически возможно. Но конфигуратор считает ещё уже не валидной и она будет обновлена при открытии. Так понятнее?

(30) Хз зачем ты это все написал [2]

(30) "ешё" --> "её"

(31) Давай, колись без этих "ХЗ", рожай уж своё (22).

20 гиговая база - это типовая бухия на 3х пользователей

(32) Это было дополнение к (11) и (12). Пользы автору конечно от этого никакой.

Ду уж. Лаконичность - не всегда сестра таланта :)

(34) Мда... эта конфигурация лежит в кэше старой базы по адресу \Config\cacheStorage. Этот файл можно подменить в кэше новой чистой базы без конфигурации... и открыть конфигуратором.

*(36) На всякий случай: это не совсем верное высказывание, точнее не в полном объёме информация, но и ветка не об этом.

У нас все не так быстро. Сначала ночной архив 70 Гигов надо достать из системы хранения. Потом вытащить бекап базы. Бекап базы 30 Гигов. Там уж быстро. Но тем не менее все займет часа 2.

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

delete from configsave
delete from config where FileName = 'commit'
delete from config where FileName = 'dynamicCommit'
delete from config where FileName = 'dbStruFinal'

Есть там такой файлик. Время подходящее, только размер 5 метров, а конфигурация 80 метров

+(40) Источник статьи http://catalog.mista.ru/public/138797/

Динамическое обновление прошло. Конфигурация базы данных успешно обновилась.

(38) Значит у тебя есть время посмотреть содержимое таблицы Config :)

(39)-(41) Это "работает" когда динамическое обновление становится демоническим :) - аварийно завершается и вы получаете ошибку что-то там про незавершённое обновление (не помню точно). У автора было "нормальное" динамическое обновление с "нормальным" завершением.

А где смотреть В SQL?

В  \Config\cacheStorage лежит файлик 5 мб. Но Конфа то 80 метров

(45) "Полноразмерный" файл вроде имеет имя ConfigCacheStorage. Но ты забей, эти кэши тебе не помогут никак.

Угу. Там конфигурация размазана по каталогам DBNameCache, ConfigSave, Config, SICache...