Все говорят, что динамическое обновление зло. Но конкретики я так и не услышал.
Действительно ли это зло, или это сказки из прошлого(первых релизов платформы 8.1-8.2)?
Естественно здесь нужно понимать, что речь должна идти:
- не об глобальных изменениях(хотя при глобальных наверняка измениться структура конфигурации и платформа не даст обновиться динамически)
- не о том функционале, где нельзя что бы пользователь, который не перезашёл, работал со старым функционалом так как это будет влиять на нужные данные
Речь идёт о небольших изменениях, в ходе которых существенного изменения алгоритма нет и можно смириться с тем, что останутся пользователи, которые работают по старому.
Пока что единственный минус, это то, что у пользователя может запомниться КЭШ и он так и будет по старой схеме работать пока у него лично не посыпятся ошибки.
Что ещё может быть?
Пока обновляю динамически, вроде приключений не встречал. Но на форумах откапывыаю ветки, где очень плохо относятся к этому делу.
(1) Vextel, в начале века случился у меня абнормал с этой фичей, чуть ли ни на 8.0
рассказал о казусе на очередном собеседовании - местные "специалисты" подняли меня на смех - фигня, мол, классная фича!
я удивился, как может быть фигней факт? но меня туда не взяли и инцидент был исчерпан
сейчас делаю, полет нормальный, хотя как раз из-за слухов по сабжу всякий раз напрягаюсь
(1) Vextel, были случаи когда повреждалась таблица config в бд, приходилось исправлять ручками, в SQL версии там попроще, средствами SQL администрирования можно снести ненужную запись, а с файловой посложнее, правил HEX редактором наугад.. ну или если запускается в пользовательском то выгружаешь всю базу в XML и загружаешь в пустую такого же релиза
(4) tango, у меня было пару раз, что похерилась таблица config.
По моему наблюдению, это случается тогда, когда динамич. обновление делается в тот момент, когда в это же время кто-то входит в базу в режиме предприятия
(1) большинство проблем с "кэшем", "вариантами отчетов" и т.д., раньше бывало что "падали" конфигурации. в последнее время инциденты с падениями конфы стали поступать реже, но не понятно с чем именно это связанно или начали реже(правильнее) использовать динамические обновления или 1С все таки что-то исправило.
если делаете просто изменение кода, то проблем вроде не возникает, в крайнем случае "грохаете" кэш пользователя и все нормализуется
(1) Vextel, имхо, демоническое обновление это зло - зло само по себе, конкретное такое зло, с рогами и копытами. Даже без типовых глюков - ситуация, когда пользователи работают в одной базе, с одними и теми же данными, но на разных конфигурациях, с различной логикой - мягко говоря пикантна.
ситуация, когда пользователи работают в одной базе, с одними и теми же данными, но на разных конфигурациях, с различной логикой - мягко говоря пикантна.
в реализации 1С - "пикантна". А вообще, есть масса вариантов реализации подобных механизмов, куда более надежных. Например, слои в Axapta, где на каждом слое - свой разработчик (основная конфа, обновления, шаблоны, доработки и т.д.). И ничего не пересекается, и друг другу не мешает. И работает.(50) AlexanderKai,
Если на SQL, то сделаешь архив
не поможет архив, т.к. последствия ломаной структуры могут всплыть спустя значительное время. Будете переносить из архива все данные за это время?
(1)
Заметил одно, при "Динамическом обновлении" перед тем как вновь внести изменения, нужно либо дождаться пока все пользователи примут предыдущее изменения, либо выгнать всех пользователей.
И важно при этом самому принять изменения, до того как обменяться с РИБ, а то после этого ошибка - Конфигурация ИБ не соответствует ожидаемой, и пляски с бубном обеспечены.
В общем динамически можно обновиться 1 раз, после чего важно чтобы все пользователи вышли из "1С:Предприятие".
Тогда и смысла большого в динамическом обновлении нет, раз всем нужно выходить.
Всем нужно выходить если после динамического обновления была обнаружена ошибка, которую можно поправить следующим изменением.
Те изменения которые делаются нужно при этом проверить хорошенько, и если не хотите гэморой, лучше перед следующим динамическим обновлением попросить граждан выйти, и объяснять при каждом удобном случае что изменения нужно применять, если база просит.
Было дело. Обновляли раньше динамически, после очередного такого обновления(просто добавили права на документ в роли) слегла база.
"повредилась таблица config". Базу подняли, но рабочее время всё равно потеряно, да и нервотрепки много. Перестали так обновляться как бы не просили.
Если уж очень припекло, выгоняем всех и обновляем.
после очередного такого обновления(просто добавили права на документ в роли) слегла база.
"повредилась таблица config". Базу подняли, но рабочее время всё равно потеряно, да и нервотрепки много. Перестали так обновляться как бы не просили.
А нужно было
delete fr om config where FileName = 'commit'
delete from config wh ere FileName = 'dbStruFinal'
При использовании динамического обновления периодически возникают различные проблемы в работе некоторых пользователей.
Решается эта проблема путем чистки каталога user\Local Settings\Application Data\1C\1Cv81 (или 1Сv8 для версии 8.0)
(10) tango, точно утверждать не могу, может и с 8.0... привычка выгонять всех осталась еще с 7.7, да и архив всеравно не сделаешь без всеобщего выхода (первое правило адинэснега), так что сталкивался с предложением динамического обновления крайне редко...
Сама всерьёз не сталкивалась. Но считаю динамическое обновление опасным. Равносильно что обновлять не постепенно, а через несколько релизов, потом не знаешь каких граблей в лоб ждать. В основном всегда стараюсь даже последовательность релизов соблюдать. А есть такие клиенты, у которых специализированные отраслевые решения и франч на свой ФТП выкидывает обновления через раз.. релизов эдак через пять и более.. бывали в итоге и проблемы в результате таких обновлений.. поэтому я динамического обновления тем более боюсь)))
Равносильно что обновлять не постепенно, а через несколько релизов
ну хоть чему-то на курсах путному научили.. не зря деньги заплатила :)
Хотя на форуме узнала бы бесплатно - но это уже нюансы.. кому-то нравится и заплатить за такое, а иначе - знание не знание :)
(15) tango, как раз причем, потому что после динамического обновления, если нажать "перезапустить конфигуратор", то он может быть уже не запустится ((. А ключики я думаю не причем.
частенько пользуюсь, здоровая управленческая самописная конфа, людей выгнать не получится - розничная торговля в 70 магазах с 10 до 22, других вариантов для срочного внесения изменений нет.
Народ, у тех у кого упала база после динамического обновления, отпишитесь на каких релизах это было, хотя бы приблизительно, ну хотя бы 8.0, 8.1, 8.2. Просто где то читал, что уже в ранних релизах платфоры 8.2 было существенное изменение в алгоритме динамического обновления.
Просто где то читал, что уже в ранних релизах платфоры 8.2 было существенное изменение в алгоритме динамического обновления.
Ага, ждите версию 10.0...
падала, падает и будет падать при дин обновлении.
Сам сталкивался с ошибкой неоткрытия после динобновления, с ошибками SDBL.
Восстанавливалось из архива, ибо возится с таблицами и наугад править все подряд - считаю, еще хуже, чем ДО. При наличии бэкапа.
Динамическое обновление в 8.2 не затрагивает таблицы данных
Так и в 8.1-8.2 оно как-бы не затрагивает таблицы данных. А сломалась структура - сломалась и база.
Или думаете, что 1С сделала раздельную обработку структуры и данных? Не дождетесь. Слабовата она для такого.
(21) Помнится на 8.1 делал без проблем. Перейдя на 8.2 (216) уже не помню получил проблему с таблица config
Сначала не мог зайти в конфигуратор, но при обновлении не запускалась и база.
Причем решение этой проблемы было найдено на просторах интернета, но 1С так и не выпустило свой инструмент решения этой проблемы. Как впрочем и решения проблемы с кэшем конфигурации.
Из опыта:
Динамическое обновление опасно при работе с распределенной базой данных.
На центральном узле может пройти все гладко.
А вот на переферийной могут возникнуть большие проблемы.
Тогда приходится "отвязывать" переферийку от центрального узла, заливать изменения в конфу руками.
Ну и так далее.
Весь этот процесс уже не раз описывался на ресурсах этого сайта.
При работе с обычными базами проблем не возникало.
Вроде как при динамическом обновлении, иногда кэш на машине пользователя не соответствует старой структуре данных...
По крайней мере автор обработки которая чистит кэш 1с из 1с так написал:
Часто, при использовании динамического обновления конфигурации, у пользователей забивается кэш и программма не работает так, как надо. Проблема устраняется путем чистки пользовательского кэша. Но основновная загвоздка в том, что не возможно определить у какого пользователя (особенно если их больше 100) кэшированные модули соотвествуют текущей версии конфигурации, а у какого нет. Программист понимает это только тогда, когда у пользователя возникла ошибка и он присылает в отдел 1С письмо с руганью, принт-скринами и матами.
Подумав, как можно очищать кэш автоматом, было решено вызывать всем известный скрипт очистки кэша непосредственно из 1С.
Могу посоветовать одно, если решитесь на динамическое обновление, делайте его на сервере 1с, у меня 2 раза накрывалась база на 8.2. После чего практикую после SQL бекапа исключительно на сервере, пока не разу не накрывалась, отсюда сделал вывод что оба прошлых раза проблема возникла из за того что конфигуратор при динамическом обновлении был открыт по сети. Восстановить файловую базу можно спомощью Tool_1CD.
8.2.16.362 Клиент-сервер x64. MSSQL 2008 R2 x64, Windows x64 2008 R2 SP1.
Динамическое обновление используется постоянно, порядка 20 пользователей одновременно + пики до 30. Конфа самописная. За год работы несколько локальных проблем с кэшем, не критичные.
Больше проблем возникает с хранилищем конфигурации, реально дурной инструмент. Обновление до 8.3 рассматриваю хотя бы чтобы подцепить конфигу на нормальный релиз трекер.
Если сильно боитесь, делайте бэкап sql. 5-10 потерянных минут это еще терпимо. Так же можно чистить кэш - иногда бывают проблемы с формами у пользователей. Плюс надо отказываться от перезапуска конфигуратора, может возникнуть ошибка, она не особо критичная, но и не очень приятная. Придется лезть с запросом в sql сервер.
Кто тут надеется на 1С и её "исправления" (стаж работы мнее 4 лет), а потому смело зааявляет "это у вас, стариков, раньше так было!" - вот про 8.2:
http://sqland1c.ya.ru/replies.xml?item_no=33
Из опыта: чаще всего базы ломались после динамических обновлений баз на Postgre. Был даже один сервер на котором динамическое обновление в 20% случаев ломало базу. Причем проглядывается явная закономерность между корректной настройкой сервера и вероятностью падения базы. Microsoft SQL и на стандартных настройках значительно стабильней работает.
чаще всего базы ломались после динамических обновлений баз на Postgre
Postgre сама по себе "глючная" (в связке с 1С), там таблицы могут побиться или "потеряться" без всякого ДО.
А некорректно ДО работает что на Postgre, что на Microsoft SQL.
Microsoft SQL и на стандартных настройках
Что еще за "стандартные настройки" SQL? Каким образом вы определили, что это - стандартное, а вот это - нестандартное?
Добрый день! Регулярно пользуюсь динамическим обновлением. Типичная проблема - в Кэше профиля пользователя на терминальном сервере остается слепок конфигурации, до динамического обновления. При следующем входе в базу пользователя подхватывается эта конфигурация, вываливаются ошибки на несуществующие, ранее удаленные процедуры и реквизиты, но которые были до динамического обновления. Приходится чистить Кеш профиля пользователя в винде. Это самое безобидное, что я встречал. А вот была ситуация, что кешированная конфа у пользователя в геометрической прогрессии осуществляла захват таблиц БД до момент полной блокировки работы всех 50 пользователей. Чистка Кэша помогла. Механизмы динамического обновления базы очень коварны. Версия 1С:Предприятие 8.3 (8.3.5.1443)
Серьезных проблем замечено не было. Динамически обновлял более 100 баз, полет нормальный. Единственная замеченная проблема - сохранение во временные файлы.
Встречался с очень серьезными проблемами после динамического обновления. Например, когда у пользователей не открывались, не проводились и нельзя было создать документы. 1с вылетала с записью памяти в дамп. Причем ошибку нельзя было выловить из логов технологического журнала, они там просто не успевали создаваться, а дам памяти не информативен.
Случалась ситуация платформа 8.2.19:
Изменили конфигурация, подгрузили динамически. прошло какое то время, замечаю что то что я исправлял месяц назад, снова появилось в коде.
пришлось второй раз исправить.
Платформа 8.2.19.121. Заметил если в течении дня проводить более 10 динамических обновлений и пользователи не перезапускают 1с, то происходит данный глюк. В настоящее время прекратил динамическое обновление.
В начале 2010-х было несколько проблем, завершившихся чисткой таблицы CONFIG на MS SQL.
В последние несколько лет ошибок не отмечалось. Наверное, исправили где-то на 8.3.6 - 8.3.8
холивар детектед. при грамотном подходе к процессу разработки, динамическое обновление становится инструментом только крайней необходимости (когда нужно срочно поправить факап).
(65) что значит грамотный подход к разработке? Вот сидит в базе несколько десятков пользователей весь день, а надо срочно что-то доработать - модули и формы документов, отчеты, интерфейс... Да мало ли бывает срочных дел? Причем часто срочно это надо одному-двум пользователям, а не всем, так вот они и перезайдут, а остальные даже не заметят, если конечно не включено оповещение об изменении конфигурации.
Может такие задачи сейчас уже решаются с помощью расширений, но кто-то ими реально пользуется? Неужели удобнее, чем динамическое обновление?
На платформе 8.3.6 ловил глюк с кэшем в клиент-серверном режиме, когда отображался старый текст модулей. Помогал выход-вход в конфигуратор. На более поздних платформах уже пофиксили.
Но глюк все еще можно словить с ошибкой нехватки памяти, крахом рабочего процесса и вылетом пользователей, если реально несколько часов динамически обновлять и обновлять, несколько десятков раз, тогда да, крыша у сервера едет. Но перезапуск сервера все лечит, ничего не теряется, но все равно надо быть осторожнее)
8.2.18.109. Большая жутко измененная УПП 1.3 на SQL сервере, 100+ пользователей регулярно. Динамическое обновление используем постоянно (за исключением реструктуризации естессно) и часто (несколько раз в день). Иногда выскакивает ошибка таблицы config. Штатно после этого можно обновиться только выгнав всех. Чтобы не выкидывать пользователей в таких ситуациях, был написан SQL триггер, спасающий config в отдельную таблицу бэкапов и хранящий там последние 10 копий этого config. Если config ломается, можно из другой базы всегда обработкой восстановить его из таблицы бэкапов. После восстановления в 99% случаев повторное динамическое обновление выполняется без ошибок.
Большая Комплексная автоматизация на SQL сервере. В силу необходимости периодически обновлялись динамически. Несколько раз после этого чистили кэш у пользователей. Но один раз через день после динамического обновления ставила обновление в монопольном режиме. Визуально все отработало благополучно. Но после обновления перестала запускаться БД, пропала возможность зайти в конфигуратор. Чистка кэша не помогла. Помог только откат на копию именно перед динамическим обновлением.
А еще динамическое обновление затирает код написаный после нормально сохранения. Т.е. пишу код в модуле, сохраняю динамически - все ок, закрываю модуль, открываю модуль обратно и все - нет моего кода! Есть старый, который был сначала..
Релиз 8,3,7 - 8,310, база скл.
Одного раза полдня работы затерло! Проверяно на разных базах...
Похоже, ТС затронула больной вопрос. Интересно было бы знать: глючность динамического обновления - это навсегда, или мы доживем до поры, когда сетования на форумах по поводу опасности динамического обновления устареют и станут неактуальны?
И потом, надо различать платформу обычную и КОРП. Возможно, уже сейчас динамическое обновление на обычной - атавизм, который позиционируется как что-то, чего быть не должно. А вот на КОРП - уже сейчас полноценный механизм.
Тоже был прикол с динамическим обновлением - база (SQL) легла... Из архива восстановился, конечно, но когда делаю динамическое обновление всегда трясусь ожидая окончания. И бывает, что при динамическом обновлении отваливается 1С-ка, и потом пишет, что при обновлении аварийная ошибка, нужно монопольно войти и повторить. Приходится выгонять всех пользюков (а их в нект. базы до 80) и обновляться. Тоже не есть хорошо.
Видимо я жутко везучий, тьфу, тьфу чтобы не сглазить!
Динамическое обновление применяю в практике, катастрофических последствий пока не наблюдал.
Хотя УПП 1.3 SQL-версия. 50-70 пользователей...
В любом случае всегда думаем можно-ли обойтись без динамического или нет. Стараемся оттащить все обновления во вне рабочее время
От знакомых программистов слышал тоже, что отгребали по полной от динамического обновления.
ИМХО, изменять конфигурацию во время работы, как это ни назови - все равно что перешивать одежду прямо на человеке, да еще когда он идет или бежит - может, все пройдет нормально, может - воткнете иголку бедолаге куда-нибудь, а может - и рукав к штанам пришьете, сзади или спереди - как получится.
После перехода на платформу 8.3.8 очень активно пользуемся динамическим обновлением, там что то явно починили.. Причем до 10 дин. обновлений в течении дня пробовали, все ок! База УТ больше 100гб, больше 150 пользоваталей онлайн.
До этого была 8.3.6, максимум 2 обновления в день прокатывало, дальше ночью надо было перезагрузить сервис агента сервера 1с. Иначе начинались проблемы с COM соединениями, то просто пользователи самопроизвольно отваливались с какими то внутренними ошибками и тд.
По поводу нужно ли дин. обновление вообще или нет, нужно однозначно - на больших базах которые активно конфигурируются каждый день и нет возможности выключить пользователей по другому никак.
В свое время столкнулся с несколькими проблемами:
1) При динамическом обновлении конфигурации произошел сбой и закрылась 1С. Ошибка: «Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?»
Исправляет два запроса, серверная база восстанавливает работу (для файловой помоему сложнее восстановить).
delete fr om config where FileName = 'commit'
delete from config wh ere FileName = 'dbStruFinal'
2) Иногда не все пользователи после динамического обновления "попадают" в "свежую" конфигурацию.
Проблема решается очисткой кэша пользователя (папки с "странными именами") в C:\Users\User\AppData\Roaming\1C\1Cv8 и C:\Users\User\AppData\Local\1C\1Cv8
Больше проблем не было замечено.
Сталкиваемся с проблемой. При постоянном и часто динамическом обновлении слетают заполнение реквизита в документах (тип - справочник, предопределенный). Бывают разные непонятные и непредсказуемые траллы, на которых нет ответа. В общем, ошибок не было никогда (обновляем на дкю по 10 раз), но могут вылезти потом подводные камни
Частенько пользуюсь динамическим обновлением. Проблем с вариантами крушения базы не было ни разу. Но...
Нашел одно большое Но.
У меня при обновлении релиза конфигурации (УПП 1.3) время от времени слетают права на мои собственные объекты конфигурации. Есть несколько добавленных регистров сведений, десяток справочников. И вот на них порой слетают все права.
Днем я обновляю конфигурацию, проверяю стандартные документы и справочники, в которых дописан мой код, чтобы мои наработки сохранились. Изменения сохраняю, а обновление конфигурации базы данных выполняю уже на удалёнке вечером из дома, когда в базе пусто.
И время от времени на следующее утро меня ждал сюрприз - мои наработки не работали по причине "Нет прав доступа...". Обнаруживали это пользователи, коих уже в базе тьма тьмущая. Залезаю в конфигуратор, восстанавливаю сброшенные права, динамически обновляюсь, проверяю работу, запуская клиента под каким-нибудь пользователем, удовлетворенно занимаюсь другими делами. Через некоторое время - Игорь, а когда 1С будет работать?
Выясняется, что прав по-прежнему ни у кого нет. Заглядываю в конфигуратор - нет прав. Точнее, есть у первого объекта, который мы проверяли, у последующих - нет. Дальше повторение прошлого - исправляем, динамически обновляемся, проверяем - работает. Ан нет, работает только в первом сеансе, в следующих установлены права только у первого и второго объектов. И так далее. Заканчивается все тем, что приходится изгнать всех, обновиться монопольно и передохнуть до выхода следующего релиза обновления.
История с кэшем пользователей тут не катит. Почему у первого объекта права сохраняются?
Выход пока вижу один - В обработчик ПриНачалеРаботыСистемы() вставить вызов своей процедурки, которая бы проверяла существование выставленных прав на список моих объектов конфигурации и при обнаружении их отсутствия изрыгала бы мессаги с красным цветом текста, чтобы срочно позвонили программисту.
Интересно, а при динамическом обновлении через механизм расширений симптомы те же, что и вышеописанные? ДО у нас используется, пока проблем почти не было - за исключением того, что в хранилище 1С вошел с терминального сервера, который ранее не использовался для конфигуратора. Пропало несколько блоков кода, благо бэкап был. С расширением пока проблем нет. обновляется значительно быстрее по понятным причинам :)
С динамическим обновлением были грабли: приходилось или "переобновлять" базу монопольно, или как минимум чистить кеш. При чём, у одних клиентов неоднократно без проблем, у других лучше и не пытаться. От чего зависит успешность динамического обновления не ясно, то ли от версии платформы 1с , то ли от других параметров.
Было, после динамического обновления появились ошибки не сразу, поэтому двое суток пришлось базу восстанавливать, т.к. уже было введено много информации.
У меня при динамическом обновлении у пользователей бывает выводятся нелепые ошибки, даже не связанные с моими изменениями, например подсистема печати недоступна, лечится чисткой кэша.Но проблема есть посложнее - обмены между базами. Насколько я понимаю - сервер 1С запуская регламентные задания в фоновом режиме запускает конфу, и обновив динамически, мы имеем то же, что и с пользователями, старую конфу в кэше(?), с которой работает регламентное задание. Сначала не мог понять в чем дело, почему появляются ошибки обмена, а сейчас после динамического обновления перезапуская службу Агент сервера 1С ошибок в обмене нет, чистить кэш смысла не вижу, т.к. у пользователя, от имени которого запускается служба нет кэша.
1С позорище, за 2 десятка лет до сих пор не сделали нормальным динамическое обновление. Например у того же Парус 8 можно спокойно ковыряться в коде или перерисовывать существующие разделы, самое худшее что может быть, до перезапуска клиента раздел работать не будет, или будет работать по старому. Целостность базы контролируется на уровне СУБД. И такого понятия как потерянные ссылки не существует. В 1с же это жесть какая то, приходится ждать ночи пока пользователи выйдут. Или там где круглосуточное производство делать оповещение о выходе всех 100500 пользователей. Короче идиотизм.
Про скорость работы и выжирание ресурсов я молчу, жрет как не в себя
8.3.18.1698, но проявлялось на нескольких 19 и, как минимум, почти всегда, на предыдущих.
Сценарий:
- зашёл в конфигуратор, изменил, например, код модуля формы объекта конфигурации и, допустим, что-то в расширении, обновил динамически.
- через 15 минут ещё что-то изменил в том же модуле, снова обновил динамически
- через 3 часа ещё что-то поправил, снова динамически
- на следующие день ещё пару правок в таком же стиле
база серверная, некоторые пользователи (из 300 примерно) по несколько дней не закрывают окно программы, в том числе при получении уведомлений о появлении изменений.
В чём, собственно, проблема: с каждым новым применением изменений время ожидания появления окна с кнопкой "Обновить динамически" сильно увеличивается, достигая через 5-6 обновлений 5-10 минут.
При этом сам механизм динамического обновления крутой, за годы его использования проблемы были смехотворные и единичные.