Не зря в народе динамическое обновление 1С называют «демоническим».
Многие утверждают что оно удобно для экстренного исправления ошибок в алгоритмах, но это самообман. На самом деле исправления для старых сессий не начнут действовать. Поведение системы, когда в разных сеансах пользователи с одними и теме же таблицами работают де-факто по разным алгоритмам — просто становится не очень прогнозируемым и стабильным.
1. Например можно словить:
Ошибка СУБД:
ERROR: relation «_reference5029» does not exist
2. Если изменилась (или удалилась) функция — будет фатальная ошибка или отсутствие контроля целостности данных.
3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем метаданных.
Кэш метаданных расположен в папке \<Имя пользователя OS>\Local Settings\Application Data\1C\1Cv81\
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку «Ошибка потока формата».
Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\<Имя пользователя>\Application Data\1C\1Cv81\ibases.v8i.
Не исключены также проблемы с падением производительности.
При этом в технологическом журнале могут встречаться сообщения типа: Попытка подключения к контексту сервера с неподходящей версией метаданных.
Возможные проблемы:
1. Основная проблема в работе с КЭШ.
1.1. У пользователя может не обновиться кэш на клиенте.
1.2. Кэш на сервере может не обновиться.
1.3. Кэш у разработчика может не обновиться (если работают несколько разработчиков)
2. Сталкивались с такой ситуацией когда делаешь штук 5 демонических обновлений а потом обычное. При обычном все демонические пропадают. Т.е. все что нажито непосильным трудом…
3. Сама ошибка заключатся в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру.
Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов
Были известны случаи, когда «демоническое обновление» останавливало работу всей системы, а исправление последствий отнимало уйму времени или базы восстанавливали из копии, потеряв часть данных.
Динамическое обновление есть смысл делать только в том случае если информационная система уже стоит, неработоспособна и хуже уже не будет. о всех остальных случаях мы рекомендуем избегать динамического обновления!
Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.
Если Вы словили проблему связанную с динамическим обновлением, то обязательно очистите сеансовые данные с рестартом службы сервера 1С.
Если проблема не ушла, то запускайте сеанс 1С с ключом /ClearCache .
Народное творчество. Порочность динамического обновления воспета народом в интернете:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без архивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:
- Анализируется корректность метаданных;
- проверяется наличие пользователей с административными правами;
- проверяется необходимость обновления структуры ИБ:
- если не понятно, что обновления структуры ИБ не требуется, запускается обновление структуры ИБ. При появлении необходимости изменения структуры делается попытка заблокировать ИБ монопольно.
- если попытка блокировки удалась — процесс обновления продолжается, динамического обновления не происходит;
- если попытка блокировки не удалась — процесс обновления завершается.
- если не понятно, что обновления структуры ИБ не требуется, запускается обновление структуры ИБ. При появлении необходимости изменения структуры делается попытка заблокировать ИБ монопольно.
- если необходимо, то обновляется информация необходимая полнотекстовому поиску;
- если необходимо, то обновляется информация требующаяся для отложенной загрузки метаданных;
- если после всех этих действий монопольная блокировка не установлена, делается попытка её установить.
- если попытка блокировки не удается — пользователю предлагается повторить блокировку или обновить ИБ динамически.
- выполняется операция обновления ИБ в обычном или динамическом режиме;
- если это динамическое обновление — в ИБ записывается разность между предыдущим и текущим поколением метаданных и информация необходимая для корректной работы.
- если это монопольное обновление и перед ним происходили динамические обновления — из информационной базы удаляются сведения об устаревших поколениях.
- если обновление происходит монопольно или динамически, но клиент подключен к файловой ИБ — конфигуратор просто обновляет свои внутренние структуры и продолжает работу. Процесс обновления ИБ завершен.
- в случае если обновление происходит динамически, но клиент подключен к клиент-серверной ИБ — конфигуратор уведомляет сервер о том, что поколение метаданных, с которым он сейчас работает, устарело. Сервер запоминает этот факт и при подсоединении первого нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору для продолжения работы после обновления ИБ требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается
В случае если обновление происходит динамически и клиент подключен к клиент-серверной ИБ, тогда конфигуратор уведомляет сервер о том, что поколение метаданных, с которым сейчас работает сервер, устарело. Сервер запоминает этот факт и при подсоединении следующего нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору, для продолжения работы после обновления ИБ, требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается, чтобы подключится к новому поколению метаданных на сервере.