ОПРОС Ошибки при динамическое обновление конфигурации
По теме из базы знаний
- Восстановление файловой версии базы данных *.1CD после ошибки динамического обновления.
- Автообмен РИБ + обновление конфигурации (если были изменения) + копирование базы перед обновлением (файловый вариант)
- Методика упрощения поддержки конфигураций. Переопределение и вызов обработчиков событий для УФ 1С 8.2-8.3
- Автоматическая очистка кэша конфигурации 1С 8.1, 8.2, 8.3 для сеанса текущего пользователя
- Динамическое обновление - это зло?
Ошибки при динамическом обновлении конфигурации
Встречал ошибки при динамическом обновлении на серверной базе (45.14%, 116 голосов)
45.14%
Не использую динамическое обновление (22.96%, 59 голосов)
22.96%
Делаю постоянно динамическое обновление - ошибок не наблюдал (19.07%, 49 голосов)
19.07%
Встречал ошибки при динамическом обновлении на файловой базе (18.29%, 47 голосов)
18.29%
Иногда делаю динамическое обновление - ошибок не наблюдал (15.56%, 40 голосов)
15.56%
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) AnryMc, все до раза) наиболее частая проблема при динамическом обновлении, с которой я сталкивался это несоответствие конфигураций на клиенте и сервере. решается элементарно /ClearCache в параметрах запуска.
пару раз был странный глюк с пропажей изменений, примененных с помощью динамического обновления. вот были, работали - фигак и нет кода - как будто не было.
но пару раз была куда более серьезная проблема - в ходе обновления вылетал конфигуратор. и оказалось что невозможно зайти в базу ни в режиме предприятия, ни в режиме конфигуратора. несколько раз ловилось "Нарушена целостность структуры конфигурации". приходилось восстанавливать таблицу config из бэкапа.
в нашей конторе полностью отказаться от динамического обновления оказалось очень сложно - применяем только в крайних случаях.
пару раз был странный глюк с пропажей изменений, примененных с помощью динамического обновления. вот были, работали - фигак и нет кода - как будто не было.
но пару раз была куда более серьезная проблема - в ходе обновления вылетал конфигуратор. и оказалось что невозможно зайти в базу ни в режиме предприятия, ни в режиме конфигуратора. несколько раз ловилось "Нарушена целостность структуры конфигурации". приходилось восстанавливать таблицу config из бэкапа.
в нашей конторе полностью отказаться от динамического обновления оказалось очень сложно - применяем только в крайних случаях.
(1) AnryMc, я тоже много лет не видел
и тут вдруг
при очередном обычном обновлении базы, с которой я работал уже года три
все упало. Вообще все. Включая сервер.
Все кончилось хорошо, но из песни слова не выкинешь.
Впрочем, я все же думаю, что это админы сервера что-то накосячили.
и тут вдруг
при очередном обычном обновлении базы, с которой я работал уже года три
все упало. Вообще все. Включая сервер.
Все кончилось хорошо, но из песни слова не выкинешь.
Впрочем, я все же думаю, что это админы сервера что-то накосячили.
(1) AnryMc, это б** пи**** какой-то, это динамическое обновление.
Обновил такой базу, через пару дней звонит человек, не работает документ говорит, ошибка такая, как-будто в модуле ошибка, отладчик ничего не показывает, что откуда, не понятно, в результате оказывается, что у человека конфигурация базы отличалась от рабочей конфигурации... ну и естественно что-то не работало. это везение если отличее не позволяет проводить документ или его печатать, сразу видно. Почистишь кеш у пользователя и работает как все, а вот если все работает, но чуток считает не так, вот это реально беда.
Обновил такой базу, через пару дней звонит человек, не работает документ говорит, ошибка такая, как-будто в модуле ошибка, отладчик ничего не показывает, что откуда, не понятно, в результате оказывается, что у человека конфигурация базы отличалась от рабочей конфигурации... ну и естественно что-то не работало. это везение если отличее не позволяет проводить документ или его печатать, сразу видно. Почистишь кеш у пользователя и работает как все, а вот если все работает, но чуток считает не так, вот это реально беда.
варианты ответов не релеванты. регулярно обновляю динамически, хотя внутренне являюсь противником такого подхода к работе, когда требуется динамическое обновление. ошибка была 2 раза. первый раз 3 года назад (стоила мне двух дней разработки), второй раз 2 недели назад (простой 1 час, восстановили благодаря статье на инфостарте и наличия хранилища конфигурации)
Бывало дважды. Восстанавливала очисткой таблиц config, configSave
далее копирование таблицы config из бэкапа
и копированием в configSave таблицы config из бэкапа
после это конфигуратор загружался и можно было обновлять.
но обновлять уже нужно в монопольном режиме, иначе будет рассогласование транспорта интерфейсов.
Сделала кучу скриншотов после второго случая, чтобы описать последовательность действий, но таки руки не дошли.
после второго раза всегда обновляюсь в монопольном режиме.
Говорят еще, что если на вопрос "перезапустить конфигуратор?" при обновлении ответить "Нет" - проблем не будет. Но я больше не рискую
далее копирование таблицы config из бэкапа
и копированием в configSave таблицы config из бэкапа
после это конфигуратор загружался и можно было обновлять.
но обновлять уже нужно в монопольном режиме, иначе будет рассогласование транспорта интерфейсов.
Сделала кучу скриншотов после второго случая, чтобы описать последовательность действий, но таки руки не дошли.
после второго раза всегда обновляюсь в монопольном режиме.
Говорят еще, что если на вопрос "перезапустить конфигуратор?" при обновлении ответить "Нет" - проблем не будет. Но я больше не рискую
(15) AnryMc,
причины ошибок и методы борьбы с ними
На полном серьёзе действенный метод борьбы (наверное единственный, но 100% рабочий): не использовать динамическое обновление. Также без доли иронии, причина ошибок в конечном итоге: сам принцип динамического обновления.
динамически обновляют и выгоняют всех из базы только трусы ))
смельчаки заводят еще одну базу на сервере, указывают путь к тому-же скулю,
и обновляют, любые изменения, штатным образом как будто в базе никого нет )))))
смельчаки заводят еще одну базу на сервере, указывают путь к тому-же скулю,
и обновляют, любые изменения, штатным образом как будто в базе никого нет )))))
(17) Boneman,
1 раз совершенно случайно именно так и получилось. заводил тестовую базу и вписал боевую базу SQL... применил монопольные изменения. слава богу ничего криминального - просто пара реквизитов для собственных справочников.
когда понял что случилось - "изрядно вспотел")) но обошлось.
смельчаки заводят еще одну базу на сервере, указывают путь к тому-же скулю,
и обновляют, любые изменения, штатным образом как будто в базе никого нет )))))
и обновляют, любые изменения, штатным образом как будто в базе никого нет )))))
1 раз совершенно случайно именно так и получилось. заводил тестовую базу и вписал боевую базу SQL... применил монопольные изменения. слава богу ничего криминального - просто пара реквизитов для собственных справочников.
когда понял что случилось - "изрядно вспотел")) но обошлось.
Я долго не делал этого после того, как попробовал его в две-тыщи-хрен-знает-каком году, когда оно ещё только появилось, и обнаружил, что новые юзеры в базу 15 минут входят. Долго переписывался с Хотлайном - попал там на адекватного сотрудника, который рассказал мне про все ужасы динамического обновления и почему эти ужасы неизбежны.
Меньше года назад стал пользоваться снова - 100 юзеров так просто не выгонишь. Пару раз пришлось чистить кэш, причём один раз на публикации цитрикса, где оказалось, что профиль юзера в явном виде отсутствует, что было весьма мрачным приколом.
Меньше года назад стал пользоваться снова - 100 юзеров так просто не выгонишь. Пару раз пришлось чистить кэш, причём один раз на публикации цитрикса, где оказалось, что профиль юзера в явном виде отсутствует, что было весьма мрачным приколом.
Дело ясное, что дело темное. Я полагаю что ошибка возникает при одновременном обращении нескольких потоков к одной и той же службе, соответственно ошибка в самой конфигурации, это мое предположение. Но в свете описанных выше проблем более динамическим обновлением пользоваться не буду, вносить изменения только после того как все пользователи выйдут. И спокойней и проблем не возникнет.
У нас сейчас бывает, что при обновлении некоторые объекты откатываются на какие-то старые версии.
Такое наблюдается иногда даже, когда обновляемся через Загрузить конфигурацию из файла по *.cf, полученной через Сохранить конфигурацию хранилища в файл :(
Может это сказываются какие-то предыдущие динамические обновления.. закономерности так и не установили.
Такое наблюдается иногда даже, когда обновляемся через Загрузить конфигурацию из файла по *.cf, полученной через Сохранить конфигурацию хранилища в файл :(
Может это сказываются какие-то предыдущие динамические обновления.. закономерности так и не установили.
У нас запрещено использование демонического обновления в продуктовом окружении. В тестовом наблюдали феерические глюки, вплоть до того, что демоническое обновление одной базы привело к неработоспособности другой базы с такой же конфигурацией в том же кластере.
(32) Мне кажется, не все здесь умеют их готовить. Сам перейдя на восьмёрку один раз нарвался на ошибку которую пытался исправить несколько дней. Тогда еще (о наивный) пытался сделать это через техподдержку 1с. Ошибка эта из всех возможных была самая незначительная (различие контрольной суммы конфигураций), но первый раз всегда страшно.
При динамическом обновлении нужно всегда помнить как его кличут в народе (демоническое). Такое название подсказывает нам, что это дело опасное и вести себя нужно как матёрый чернокнижник при вызове демона.
Есть несколько простых правил, соблюдая которые можно многократно снизить риск появления ошибки:
1. Отключать фоновые задания на время обновления.
2. Не накладывать обновления одно на другое. Т.е. Прежде чем загрузить в центральную очередное обновление, необходимо чтобы это обновление прошло по всем дочкам и они прислали ответ уже с новой конфигурации.
3. Желательно рестартить службу сервера 1с во время наименьшей нагрузки и не забываем про кэш.
Остальные очевидные вещи типа бэкапов и изучения SQL объяснять не буду. Рискуя, вы должны быть готовы всё исправить быстро и профессионально.
При динамическом обновлении нужно всегда помнить как его кличут в народе (демоническое). Такое название подсказывает нам, что это дело опасное и вести себя нужно как матёрый чернокнижник при вызове демона.
Есть несколько простых правил, соблюдая которые можно многократно снизить риск появления ошибки:
1. Отключать фоновые задания на время обновления.
2. Не накладывать обновления одно на другое. Т.е. Прежде чем загрузить в центральную очередное обновление, необходимо чтобы это обновление прошло по всем дочкам и они прислали ответ уже с новой конфигурации.
3. Желательно рестартить службу сервера 1с во время наименьшей нагрузки и не забываем про кэш.
Остальные очевидные вещи типа бэкапов и изучения SQL объяснять не буду. Рискуя, вы должны быть готовы всё исправить быстро и профессионально.
(34)
Проще если пользователей не больше десяти. А если сотня?
(35)
Вы также как и предыдущий автор подменяете смысл моего сообщения. Не знаю, осознанно или действительно не понимаете. Повторю расставив акценты:
(35)
Ключевое слово если. Данное действие как раз и предотвращает наиболее распространенные ошибки.
(36) Да, верно. Речь идёт о последовательных ДО которые идут одно за другим. Т.е. перед тем как поставить очередное обновление -мы должны иметь ответ от дочки с предыдущим ДО.
В целом соблюдение этих нехитрых правил - просто исключило из списка моих проблем последствия ДО. Часто просят помочь восстановить базы убитые ДО, но каждый раз причина - нарушение одного из трёх правил безопасности.
- тогда динамическое обновление полностью теряет смысл! Проще сразу всех выгнать
Проще если пользователей не больше десяти. А если сотня?
(35)
Если "сломается" рабочая база - какая разница, какое обновление, и где оно в "дочках"?
Вы также как и предыдущий автор подменяете смысл моего сообщения. Не знаю, осознанно или действительно не понимаете. Повторю расставив акценты:
Желательно рестартить службу сервера 1с во время наименьшей нагрузки и не забываем про кэш
Т.е. обновление по потребности, а рестарт службы и кэш по возможности
(35)
Если "сломается" рабочая база - какая разница, какое обновление, и где оно в "дочках"?
Ключевое слово если. Данное действие как раз и предотвращает наиболее распространенные ошибки.
(36) Да, верно. Речь идёт о последовательных ДО которые идут одно за другим. Т.е. перед тем как поставить очередное обновление -мы должны иметь ответ от дочки с предыдущим ДО.
В целом соблюдение этих нехитрых правил - просто исключило из списка моих проблем последствия ДО. Часто просят помочь восстановить базы убитые ДО, но каждый раз причина - нарушение одного из трёх правил безопасности.
(33) Артано, у вас в п.3 нет никакого ДО.
И кэш, и служба - нужно останавливать работу всех.
И кэш, и служба - нужно останавливать работу всех.
Не накладывать обновления одно на другое.
Если "сломается" рабочая база - какая разница, какое обновление, и где оно в "дочках"?
Мне кажется, не все здесь умеют их готовить.
А мне сдается, что многие просто ходят и дразнят спящую собаку в лице ДО, и отбежав, похваляются на форумах, какие они храбрые ))
При динамическом обновлении возникали ошибки, поэтому отказались от него. Сейчас вносим изменения, сохраняем, а по ночам отрабатывает батник вида.
В результате происходит имплементация(модное словечко) изменений.
Недостаток - изменение растягивается во времени. То есть сегодня заводим новый реквизит, ночью обновляется конфа и только завтра начинаем использовать этот реквизит.
"C:\Program Files (x86)\1cv82\common\1cestart.exe" CONFIG /SСервер/База /NАдминистратор /PПарольАдмина /UpdateDBCfg /outПутьКЛогам\1cUpdCfg.log
В результате происходит имплементация(модное словечко) изменений.
Недостаток - изменение растягивается во времени. То есть сегодня заводим новый реквизит, ночью обновляется конфа и только завтра начинаем использовать этот реквизит.
(52) AlexO, пример можно? А то тут один товарищ добавил триггеры на Insert и посмотрел, что делает динамическое обновление. А оно, как оказалось, определенным образом накатывает данные в таблицы конфигураций, таблицы данных не трогаются. Тем более динамическое обновление при необходимости реструктуризации, как мы знаем, в принципе не работает.
[quote]В ходе анализа статистической информации из таблицы [Master].[dbo].[Config_Insert] выяснилось, что само обновление представляет из себя просто последовательную запись в таблицу строк содержащих файлы метаданных и файлы описаний конфигурации (обезательные “root”,”version”,”versions”) , а также, что существует несколько вариантов обновления (если судить по изменениям в таблице Config)[/quote]
Т.е. при обновлении ничего такого сверхвыдающегося не происходит - записываются данные в табличку конфигурации. Реструктуризация происходит только при обычном обновлении. В итоге если бакапить таблицу конфигурации, то проблем быть не может. Но если Вы укажите на конкретную проблемы, выходящую за рамки таблицы конфигурации, то мы можем об этом подискутировать.
[quote]В ходе анализа статистической информации из таблицы [Master].[dbo].[Config_Insert] выяснилось, что само обновление представляет из себя просто последовательную запись в таблицу строк содержащих файлы метаданных и файлы описаний конфигурации (обезательные “root”,”version”,”versions”) , а также, что существует несколько вариантов обновления (если судить по изменениям в таблице Config)[/quote]
Т.е. при обновлении ничего такого сверхвыдающегося не происходит - записываются данные в табличку конфигурации. Реструктуризация происходит только при обычном обновлении. В итоге если бакапить таблицу конфигурации, то проблем быть не может. Но если Вы укажите на конкретную проблемы, выходящую за рамки таблицы конфигурации, то мы можем об этом подискутировать.
(53) starik-2005,
Боюсь, как бы вам не хотелось - вы не сможете все проблемы подвести под "достаточно "забэкапить таблицу конфигурации".
Проблема - в неправильном/неконтролируемом чтении-записи темповых файлов.
И эта проблема не только с ДО "всплывает".
пример можно?
Пример чего? Битой конфы?
А оно, как оказалось, определенным образом накатывает данные в таблицы конфигураций, таблицы данных не трогаются
Это и так давно понятно. Только толку-то - если ДО портит структуру, то и данные уже не получишь. Даже если они целые.
Но если Вы укажите на конкретную проблемы, выходящую за рамки таблицы конфигурации
ДО генерирует проблемы от "что-то глючить стало" - до "база не открывается".
Боюсь, как бы вам не хотелось - вы не сможете все проблемы подвести под "достаточно "забэкапить таблицу конфигурации".
Проблема - в неправильном/неконтролируемом чтении-записи темповых файлов.
И эта проблема не только с ДО "всплывает".
(54) AlexO,
[quote]ДО и не такое "умеет", к сожалению.[/quote]
Вот этого "и не такое". Что "не такое" умеет ДО?
[quote]если ДО портит структуру, то и данные уже не получишь[/quote]
Э... А как структура и данные зависят? Есть в скуле сто табличек с данными и одна табличка с конфой 1С, которая после ДО оказалась запоротая. Восстанавливаете табличку с конфой - и все, данные тут ни разу не участвуют, т.к. это разные таблички. Не надо путать структуру 1С со структурой SQL - они в разных местах хранятся.
"Темповые" файлы - это кеш? Глюки с кешем не только от ДО могут появиться, поэтому чистите его периодически.
[quote]ДО и не такое "умеет", к сожалению.[/quote]
Вот этого "и не такое". Что "не такое" умеет ДО?
[quote]если ДО портит структуру, то и данные уже не получишь[/quote]
Э... А как структура и данные зависят? Есть в скуле сто табличек с данными и одна табличка с конфой 1С, которая после ДО оказалась запоротая. Восстанавливаете табличку с конфой - и все, данные тут ни разу не участвуют, т.к. это разные таблички. Не надо путать структуру 1С со структурой SQL - они в разных местах хранятся.
"Темповые" файлы - это кеш? Глюки с кешем не только от ДО могут появиться, поэтому чистите его периодически.
(55) starik-2005,
1С не умеет работать со своим кэшем. Какие бы там "системные таблицы" не были (а в 1С8 ее "системная" таблица - не "основная", как было в 7.7) - в 1С они меняются "на живую" и без всякого контроля с её стороны.
А как структура и данные зависят?
Так, что структура таблиц SQL не зависит от структуры "таблиц" 1С. В SQL будет все отлично, в 1С - запорото.
Не надо путать структуру 1С со структурой SQL - они в разных местах хранятся.
Дело не в этом. В чем - написал выше.
1С не умеет работать со своим кэшем. Какие бы там "системные таблицы" не были (а в 1С8 ее "системная" таблица - не "основная", как было в 7.7) - в 1С они меняются "на живую" и без всякого контроля с её стороны.
(56) AlexO, а что такое:
[quote]в 1С они меняются "на живую" и без всякого контроля с её стороны[/quote]
Если я правильно понял, то Вы говорите, что "системные таблицы меняются на живую без всякого контроля со стороны 1С"? Ничего не понял. Вы что сказать-то хотели? И как это противоречит тому, что бакап таблицы с конфой при ДО поможет избежать трудностей с восстановлением базы, позволяя решить проблему восстановлением одной только таблицы за "питнадцать сикунд"?
[quote]в 1С они меняются "на живую" и без всякого контроля с её стороны[/quote]
Если я правильно понял, то Вы говорите, что "системные таблицы меняются на живую без всякого контроля со стороны 1С"? Ничего не понял. Вы что сказать-то хотели? И как это противоречит тому, что бакап таблицы с конфой при ДО поможет избежать трудностей с восстановлением базы, позволяя решить проблему восстановлением одной только таблицы за "питнадцать сикунд"?
(57) starik-2005,
Не понимаю, какая связь между таблицей Config и пропавшими ранее работающими формами или пропавшим текущим кодом изменения. Как вы это восстановите "таблицей"?
(55) starik-2005,
И как это противоречит тому, что бакап таблицы с конфой при ДО поможет избежать трудностей
Ваше понимание 1С как "это набор таблиц SQL" и желание все свести "к одной таблице" сыграет вам когда-нибудь плохую службу.
позволяя решить проблему восстановлением одной только таблицы за "питнадцать сикунд"
Не понимаю, какая связь между таблицей Config и пропавшими ранее работающими формами или пропавшим текущим кодом изменения. Как вы это восстановите "таблицей"?
(55) starik-2005,
Глюки с кешем не только от ДО могут появиться, поэтому чистите его периодически.
Как вы будете чистить кэш, если делаете ДО? С чисткой кэша "за "питнадцать сикунд" и ДО не нужно - тут же и обновиться.
(58) AlexO, [quote]Ваше понимание 1С как "это набор таблиц SQL" и желание все свести "к одной таблице" сыграет вам когда-нибудь плохую службу. [/quote]
Полагаю, что Ваше "№понимание" данных, как что-то такое внутри черного ящика 1С не даст Вам эффективно решать сложные задачи производительности и восстановления данных. Это просто разный уровень Дзен. "Ищите - и обрящите" (с).
[quote]Не понимаю, какая связь между таблицей Config и пропавшими ранее работающими формами или пропавшим текущим кодом изменения. Как вы это восстановите "таблицей"? [/quote]
Истинный программер знает, что данные в SQL хранятся отдельно от метаданных, но метаданные тоже хранятся в SQL. Читайте это, пока не сойдет на Вас просветление.
[quote]Как вы будете чистить кэш, если делаете ДО?[/quote]
Кеш хранит некоторые данные с сервера на клиенте, чтобы не читать эти данные с сервера еще раз. При динамическом обновлении метаданные для "старых" пользователей не меняются, а для новых меняются. Это справедливо и для вызова серверных процедур. Когда пользователь захочет увидеть новое - он должен будет перезайти в программу. В это время Дзен рекомендует чистить кеш. Читать до полного просветления.
Полагаю, что Ваше "№понимание" данных, как что-то такое внутри черного ящика 1С не даст Вам эффективно решать сложные задачи производительности и восстановления данных. Это просто разный уровень Дзен. "Ищите - и обрящите" (с).
[quote]Не понимаю, какая связь между таблицей Config и пропавшими ранее работающими формами или пропавшим текущим кодом изменения. Как вы это восстановите "таблицей"? [/quote]
Истинный программер знает, что данные в SQL хранятся отдельно от метаданных, но метаданные тоже хранятся в SQL. Читайте это, пока не сойдет на Вас просветление.
[quote]Как вы будете чистить кэш, если делаете ДО?[/quote]
Кеш хранит некоторые данные с сервера на клиенте, чтобы не читать эти данные с сервера еще раз. При динамическом обновлении метаданные для "старых" пользователей не меняются, а для новых меняются. Это справедливо и для вызова серверных процедур. Когда пользователь захочет увидеть новое - он должен будет перезайти в программу. В это время Дзен рекомендует чистить кеш. Читать до полного просветления.
(60) Артано, мы с AlexO просто любим, полагаю, отстаивать свою точку зрения. Скучно ведь, когда и поспорить не с кем. А я на спорах в свое время собаку съел. Сначала доказывал атеистам, что землю за шесть дней сотворили, потом доказывал сектантам, что большой взрыв - вполне реальное событие. А уж на фоне этого всякие специализированные вещи, которыми я уже лет 30 занимаюсь, редко оставляют шансы оппонентам на их мнение. С другой стороны всегда приятно почувствовать себя идиотом, чтобы стать еще умнее.
Применяем демоническое обновление только в крайних случаях, когда уж очень срочно что-то пользователям нужно.
На некоторых базах в основном без ошибок, а на некоторых бывают ошибки, которые лечатся очисткой кэша у пользователей.
На некоторых базах в основном без ошибок, а на некоторых бывают ошибки, которые лечатся очисткой кэша у пользователей.
Много раз делал динамическое обновление, все проходило гладко. Один-единственный раз база сказала "ты кто такой? давай до свиданья!" и легла. К счастью, бэкап был под рукой и все восстановили в течении часа.
(База осталась по наследству):
1. Замечено было неоднократно дублирование реквизитов (N-раз) при N-раз динамическом обновлении (в метаданных) - пред дев-а;
2. Дублирование объектов (N-раз) при N-раз динамическом обновлении (в дереве метаданных);
3. Ну и кеш (всех рабочих соединений приходилось чистить), куда же без него(
пока так.
1. Замечено было неоднократно дублирование реквизитов (N-раз) при N-раз динамическом обновлении (в метаданных) - пред дев-а;
2. Дублирование объектов (N-раз) при N-раз динамическом обновлении (в дереве метаданных);
3. Ну и кеш (всех рабочих соединений приходилось чистить), куда же без него(
пока так.
ПРОМЕЖУТОЧНЫЕ ВЫВОДЫ:
Если убрать результаты пункта "Не использую динамическое обновление" т.к. они не влияют соотношение: "Есть ошибки" / "Нет ошибок", то получается
вероятность "нарваться на ошибку" примерно 60 %
ЗЫ
1) "Картинка" не совсем соответствует истине т.к. нет статистики: сделал динамических обновлений / из них неудачных.
2) В основном "этим недугом" страдают серверные базы, но проблемы довольно легко лечатся... (О фатальном разрушении я сообщений не увидел вообще!)
3) Про фирму 1С которая дает этот механизм с такой статистикой - просто молчу!
Если убрать результаты пункта "Не использую динамическое обновление" т.к. они не влияют соотношение: "Есть ошибки" / "Нет ошибок", то получается
вероятность "нарваться на ошибку" примерно 60 %
ЗЫ
1) "Картинка" не совсем соответствует истине т.к. нет статистики: сделал динамических обновлений / из них неудачных.
2) В основном "этим недугом" страдают серверные базы, но проблемы довольно легко лечатся... (О фатальном разрушении я сообщений не увидел вообще!)
3) Про фирму 1С которая дает этот механизм с такой статистикой - просто молчу!
Самое фееричное что происходило в моем опыте с динамическим обновлением.
Пользователи работали в гурппе терминалов - раскидывало по ним равномерно по загрузке оных.
Каталог профиля сот-но мигрировал между терминалами.
Так вот иногда у людей чуть ли не 2-3 месячной давности кэши всплывали.
Сейчас наблюдаю событие, которое пока не могу описать почему так.
У некоторых пользователей даже после чистки кеша он иногда подгружается старый.
Остановка по ошибке происходит в одних и тех же местах модуля одного. При том что при открытии конфигуратора с машины пользователя - даже код модуля уже новый видно - а ошибка такая же, как была до обновления месячной давности.
Закономерности подгрузки старой версии кеша пока не выявлено.
Пользователи работали в гурппе терминалов - раскидывало по ним равномерно по загрузке оных.
Каталог профиля сот-но мигрировал между терминалами.
Так вот иногда у людей чуть ли не 2-3 месячной давности кэши всплывали.
Сейчас наблюдаю событие, которое пока не могу описать почему так.
У некоторых пользователей даже после чистки кеша он иногда подгружается старый.
Остановка по ошибке происходит в одних и тех же местах модуля одного. При том что при открытии конфигуратора с машины пользователя - даже код модуля уже новый видно - а ошибка такая же, как была до обновления месячной давности.
Закономерности подгрузки старой версии кеша пока не выявлено.
Может кому пригодится, заметил на клиент-сервере, что ошибки динамического обновления встречаются чаще если конфигуратор долго висит открытым (видимо влияют провалы в соединении). Таким образом перед динамическим обновлением лучше сохранить конфигурацию и перезапустить конфигуратор.
В другой ветке уже писал, но повторюсь:
1. Динамическое обновление после выхода из клиента имеет очень высокие шансы пройти с ошибкой; наоборот, обновление с трассируемым клиентом, который вы соглашаетесь для обновления закрыть по просьбе конфигуратора, имеет крайне низкие шансы пройти с проблемами.
Хотя по элементарной логике должно быть наоборот).
2. Если клиент после динамического обновления не грузится, создаю любую константу, удаляю её и обновляюсь по-новой (даже динамически).
3. Не обновляться динамически сразу же после динамического обновления! Пойдите покурите или сделайте себе чай. После чего обновляйте. Возможно, проблема касается 1 минуты, возможно чуть больше, но, похоже, что при двух повторных обновлениях подряд мы получаем критическую ситуацию, после которой, не зная пункта 2. можно остановить работу всего предприятия.
1. Динамическое обновление после выхода из клиента имеет очень высокие шансы пройти с ошибкой; наоборот, обновление с трассируемым клиентом, который вы соглашаетесь для обновления закрыть по просьбе конфигуратора, имеет крайне низкие шансы пройти с проблемами.
Хотя по элементарной логике должно быть наоборот).
2. Если клиент после динамического обновления не грузится, создаю любую константу, удаляю её и обновляюсь по-новой (даже динамически).
3. Не обновляться динамически сразу же после динамического обновления! Пойдите покурите или сделайте себе чай. После чего обновляйте. Возможно, проблема касается 1 минуты, возможно чуть больше, но, похоже, что при двух повторных обновлениях подряд мы получаем критическую ситуацию, после которой, не зная пункта 2. можно остановить работу всего предприятия.
Сталкивался неоднократно. Критические ошибки (рассогласование базы со структурой метаданных, а не просто кривой модуль) бывают, но очень редко (за многолетнее использование раза три или четыре такое наблюдал). Для этого требуется стечение многих обстоятельств.
Как правило, максимальная вероятность наступления проблем наступает при многократном динамическом обновлении подряд и сбойном кэше конфиругации.
Выработалась такая технология: рабочая база никогда не правится руками, только загружаются изменения конфы из хранилища. Вроде при такой схеме даже сбойный кэш не ведет к проблемам. Это не убирает проблемы забросить в хранилище что-то не то из тестовой базы со сбойным кэшем, но на тестовых базах обычно нет необходимости в динамических обновлениях, поэтому и кэш там порядке, как правило
Как правило, максимальная вероятность наступления проблем наступает при многократном динамическом обновлении подряд и сбойном кэше конфиругации.
Выработалась такая технология: рабочая база никогда не правится руками, только загружаются изменения конфы из хранилища. Вроде при такой схеме даже сбойный кэш не ведет к проблемам. Это не убирает проблемы забросить в хранилище что-то не то из тестовой базы со сбойным кэшем, но на тестовых базах обычно нет необходимости в динамических обновлениях, поэтому и кэш там порядке, как правило
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот