Подскажите пожалуйста как решить проблему.
УПП 1с 8.3.
Периодически обновляюсь динамически. Последнее время стал замечать, что некоторые обновления затираются следующим. Не могу понять причину.
Обновляюсь ч/з хранилище. Все работает. на следующий день делаю новое обновление, предыдущее затирается.
Если посмотреть историю хранилища в рабочей базе, то они в списке есть, но если открыть код, там их нет.
Если в копии открыть тот же код, то там эти изменения есть. Хранилище одно и тоже. В результате в копии снова делаю захват в хранилище, в код добавляю пробел (чтобы была модификация) помещаю в хранилище и снова обновляюсь в рабочей базе.
Но это же не дело.
УПП 1с 8.3.
Периодически обновляюсь динамически. Последнее время стал замечать, что некоторые обновления затираются следующим. Не могу понять причину.
Обновляюсь ч/з хранилище. Все работает. на следующий день делаю новое обновление, предыдущее затирается.
Если посмотреть историю хранилища в рабочей базе, то они в списке есть, но если открыть код, там их нет.
Если в копии открыть тот же код, то там эти изменения есть. Хранилище одно и тоже. В результате в копии снова делаю захват в хранилище, в код добавляю пробел (чтобы была модификация) помещаю в хранилище и снова обновляюсь в рабочей базе.
Но это же не дело.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Надо же. Остались живые люди, которые не в курсе про глюки кэша конфы при динамических обновлениях.
По существу:
1) конфа при работе 1С кэшируется локально в профиле пользователя
2) при динамических обновлениях кэш нередко начинает глючить (не обновляется)
3) самый простой способ почистить локальный кэш конфы (чтобы не лазить руками в профиль) - удалить базу из списка баз и добавить снова.
По существу:
1) конфа при работе 1С кэшируется локально в профиле пользователя
2) при динамических обновлениях кэш нередко начинает глючить (не обновляется)
3) самый простой способ почистить локальный кэш конфы (чтобы не лазить руками в профиль) - удалить базу из списка баз и добавить снова.
(2)
Оно конечно все так, но если работать через хранилище - то код реально затирается зачастую, просто обновляешь из хранилища все ок, все работает, через день новое обновление - оно тоже ок и работает, но первое просто пропадает из кода, и удаление из списка в этом случае не помогает...
ских обновлениях кэш нередко начинает глючить (не обновляется)
3) самый простой способ почистить локальный кэш конфы
3) самый простой способ почистить локальный кэш конфы
Оно конечно все так, но если работать через хранилище - то код реально затирается зачастую, просто обновляешь из хранилища все ок, все работает, через день новое обновление - оно тоже ок и работает, но первое просто пропадает из кода, и удаление из списка в этом случае не помогает...
(3) Из-за сбойного кэша на одной из копий можно элементарно поместить в хранилище изменения, затирающие предыдущие обновления. Слава богу хранилище позволяет откатиться. Ну и ревью надо делать для заливаемых в рабочую базу изменений. А чтобы избежать проблем сбоя кэша на рабочей базе, нужно соблюдать простое правило: никогда не редактировать конфу рабочей базы руками - только заливать изменения из хранилища.
Была такая же проблема при автоматическом обновлении из хранилища. Суть в том, что динамическое обновление создает временные объекты в таблице конфиг, которые являются обновленными версиями предыдущих. По всей видимости при автоматическом обновлении из хранилища эти динамические обновления могут просто затираться, т.е. они не переносятся в основные объекты, но при этом удаляются все динамически обновленные объекты конфигурации.
Чистка кеша, на сколько я знаю, проблемы не решала. У нас вообще сначала к базе запрещались коннекты, потом стопился сервер, потом чистился кеш и очищался каталог контекста, потом сервер стартовал, потом запускалось обновление, выгруженное в cf из хранилища, потом разрешались подключения. И периодически при таком подходе грохались все динамические обновления. При том, на сколько я помню, грохались только в том случае, если динамических обновлений было больше 1-го.
Чистка кеша, на сколько я знаю, проблемы не решала. У нас вообще сначала к базе запрещались коннекты, потом стопился сервер, потом чистился кеш и очищался каталог контекста, потом сервер стартовал, потом запускалось обновление, выгруженное в cf из хранилища, потом разрешались подключения. И периодически при таком подходе грохались все динамические обновления. При том, на сколько я помню, грохались только в том случае, если динамических обновлений было больше 1-го.
(6) "потом запускалось обновление, выгруженное в cf из хранилища" - другими словами вы загружали cf хранилища, замещая им рабочую конфа?
Единственный вариант, при котором при этом могли "грохнуться все динамические обновления" - отсутствие этих обновлений в хранилище.
Единственный вариант, при котором при этом могли "грохнуться все динамические обновления" - отсутствие этих обновлений в хранилище.
(7)
отсутствие этих обновлений в хранилище
Нет. В хранилище были эти изменения. В платформе есть такой баг, который достаточно давно уже там живет. 1-е динамическое обновление добавляет сохраняет объект как новый, оставляя старый объект нетронутым. Новый объект получает некоторый уникальный суффикс. Следующее динамическое обновление создает еще одну копию объекта - и так далее. Видимо при обновлении 1С смотрит на первые копии объекта, и если есть вторые и третьи, то эти объекты, по всей видимости, игнорируются, просто удаляясь из конфигурации. Правильно было бы удалить все экземпляры объектов, кроме последнего, но, видимо, что-то идет не так и удаляются все экземпляры динамически обновленных объектов, если по ним в cf-нике нет изменений. Если изменения у объекта есть, то этот объект обновляется.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот