Знаю что раньше были проблемы в этом механизме, как сейчас????

Трус не играет в хоккей!

(0) Если распределёнка - никаких динамических обновлений! Да и вообще оно - зло.

настолько, насколько безопасно ходить по льду. Я вот пару раз проваливался, но слава богу выбрался без последствий

мне больше интересно, насколько безопасно реализована фоновая реструктуризация информационной базы в 8.3

по теме - никогда не использую динамическое обновление 8.2 и никому не советую

50/50

(2) ага, ну да, это на этапе внедрения скажи... когда криты повалятся

Не безопасно и сейчас.

много раз пользовался и раньше и сейчас, никаких глюков не обнаружил...

(9) + 0.5 раз пять нарывался на битую конфигу у юзера в профиле

Выстрелить себе в коленку - гораздо менее опасное мероприятие

+(9) все базы были серверные. на файловых не пробовал...

(11) если ты Кержаков

Пару раз нарвались.
С тех пор - ни-ни.

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

(4) Там механизм достаточно простой. Если накуролесили и там - это ни в какие ворота.

(15) Перевожу: для того, чтобы демонически обновлять боевую базу нужно находиться в той же стадии идиотии, которая позволяет из интереса пальнуть себе в колено. Я не идиот, делать не буду ни того, ни другого.

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

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

Нормально работает, разок словили косяк - быстренько восстановили таблицу с метаданными  из бакапа и вперед. И то косяк вышел из-за того, что подвис процесс обновления, и не дождавшись окончания его срубили.

(18) А тестировать доработки до наката в боевую базу форум считает трусостью? Это что ж за херню нужно постить в рабочую базу, что нельзя дождаться окна регламентного обслуживания?

постоянно пользуюсь, в целом ничего, только глюки с кэшем.

один раз правда тыща накладных нахреначились с неправильными ценами из-за этого..

Так ясен пень, что все кто против - либо сами попробовали, либо со стороны видели как у кого-то что-то нахреначилось, а потом задница месяц болела. Иногда косяк в данных обнаруживается спустя 3-4 часа. На ваших любимых системах с сотнями пользователей это значит, что и бэкап уже не поднять и текущие данные терять нельзя. Еще смешнее, когда пропадают доработки, не связанные с текущей правкой. Доработали контроль остатков, через неделю динамически обновили какую-то мелочь вроде подстановки реквизитов по умолчанию в форме, еще через неделю пользователи в шоке спрашивают, как так сделали контроль остатков, что он в минуса позволяет выйти? А нету больше контроля остатков, демоническое обновление тот модуль из кэша предшестующей ему версии подцепило. Возрадуйтесь, вам нужна инвентаризация! А вы обновляйте, обновляйте.
Улыбок тебе дед макар.

(23) Кеш почистить перед обновлением?
Маленькая алкогльная компания, торговые работают до 8-9, склад, отдел выпуска документации до 5-6утра соответсвенно, с 6-7 регламетные процедуры. Ну да, остается часик до 8.

(0) пол форму пишут что это "зло"

у меня лично не разу не было проблем с этим.

(25) интересно,
>у меня лично не разу не было проблем с этим.
Из одной касты в другую переходят по этому признаку

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

Видимо не у меня одного все норм обновляется:
(9)
(19)
(20)
(22)

Я как пользовался так и буду, т.к. вещь идеальная. Бэкапы раз в сутки идут, если даже база сдохнет просто сделаю перенос данных в старых бэкап.

(27)> перенос данных в старых бэкап
механизм отработан, сколько времени занимает? Сколько пользователи без базы просидят? Обновляться раз в сутки?

Частенько балуюсь демоническим обновлением на рабочей базе с 20-30 онлайн пользователей.
Раза 2-3 база рушилась при реструктурзации. Но тем не менее - удобно.

(0) норм все с динамическим обновлением.
тьфу тьфу за последние пару лет и не припомню проблем.

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

буду и дальше пользоваться этой замечательной технологией

(30) бека скока делается? Если часик, два?

(0) ну, если ты любишь плавающие ошибки неизвестно откуда и танцы с бубном, то это для тебя...

(28) не пойму ты за динам. обновление или против? Сколько времени занимает выгнать 200 юзеров из базы, что бы начать обновить пару строк кода которые влияют на работу? Ммм? Сколько из них за компом, ммм?

(29) самое смешное да, что он не дает делать динам. обновление когда нужно реконструировать базу, там просто нет кнопки "Обновить динамически".

(31) часик - два бэкап? тогда машину на свалку

У меня 8.2.15 - за пять месяцев один раз было, что при динамическом обновлении конфигуратор тупо вылетел. Я в тот вечер поседел :-)

За последние 5 лет ни разу не потребовалось динамическое обновление. Либо проблема мелкая или есть обходное решение и ждет до регламентного окна. Либо настолько серъёзная, что все выйдут.

(31) сразу налицо обширный опыт работы с субд... на рукалицо...

(25) Если заниматься незащищенным сексом с незнакомыми лицами противоположенного пола (привет новому закону), то у многих тоже все хорошо. Вот только есть несчастливчики.
Я предпочитаю недопускать вероятность появления проблем, чем устранять их появление.

Я пользуюсь. Проблем пока не было.

(33) Вчера не влияли сегодня влияет? по времени, ну часа полтора, написать всем на почту за час. За 10 минут предупредить. За 5 минут в конфигураторе завершить сеансы (38) Вы про ежедневные и инкрементые обновления?

(39) хозяин барин!

Можешь тоже самое написать для (40)

я думаю если есть такая отличная функция, надо ею пользоваться. Например там у Вася Пупкина что то левое убило базу, а он просто "подумал" на динобн и начал писать ан форуме "динобн зло!1111 убивала база!!11".

(39) вот так сразу, даже имя не спросить?

(41) некоторые проводят документ в которых по 400 - 1000 сотрудников, например расчет / начисление зарплаты, все из базы выходят и ждут пока пройдется документ.


не спорю, для фирмы где 5 сотрудников динобн не нужно

(41) я про бекап средствами субд

(45) Прикидай, бекап на скл час, положить/поднять, инкреметые бекапы фича скуль базы

(21) по разному бывает, я как то вечерком запустил ТиИ а оно возьми и не успей к началу рабочего дня. А всё из-за того что пользователь в бухии провёл документ 201 году (ну промахнулся, рука по пъяни дрогнула). И программа с 201 года по 2013 пересчитывала итоги...

Так что не всегда есть возможность всё проверить на тестовой

(43)Когда-то в молодости бывало, что на другой день даже имени вспомнить не мог женщины, с которой переспал.

(47) дата запрета изменения НЕ?

(46) Если база терабайт, то час.
Если в районее 200 Гигабайт - на 2008 архив сжатый делается порядка 20 минут. SQL 2008R2

(47) у меня так же главбухша пару раз делала))) за прошлый год случайно в документ заходила и жала ОК у неё полные права. до тех пор пока с вертухана не покарал её.

(39)Даже после этой ветки кто-то сделает вывод, что динамическим обновлением заниматься нельзя, а кто-то - что можно, но с предосторожностями. Цена вопроса - при самом худшем раскладе получить выговор.

(49) не

А почему все так уверены, что всего лишь обновление в монопольном режиме дает гарантию 100% чистого кэша на клиентских машинах?

Динамическое обновление, если используются обмены с включенными РИБ, выполняющимися в фоновом режиме... Вероятность возникновения ошибок есть. Но и монопольное обновление все равно может вызвать сообщение "конфигурация узла не соответствует ожидаемой" - это сообщение больше зависит от характера изменений, чем от способа обновления.

В общем, 100% гарантии не существует, что в процессе обновления (любого) ничего с базой не случится. Просто если база находится в монопольном режиме, то вероятность появления ошибок ниже и вероятность их безопасного исправления выше. Бакапы все равно нужны. Не будет бакапа - риск намного серьезней.

(54)А еще во время обновления может зависнуть рабочая станция или выйти из строя источник бесперебойного питания.

http://infostart.ru/public/190249/

:)
или кто-то из юзеров обидится, что его из базы выперли, а кнопки "сделать все" так и не сделали

(52) Или еще вариант - динамически обновляться можно, но оно того не стоит.

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

а че голосилку не прикрутили? Все б видно сразу стало. Иногда, из-за строчки кода делаю обновление демоническое. Тогда, емнип, реструктуризация не происходит. один раз нарвался на fail в тестовой базе, правда, ну ничего, ттт, все нормально.
Действительно, выгонять пользователей, когда у тебя непрерывный цикл производства - целая песня.

бывет делаю демоническое, но редко... (примерно 1 раз в месяц или еще реже)

руководствуюсь следующим, если проблемма терпит до завтра - значит утром когда никого нет.
если горят отгрузки/платежи и т.д. - демонически

Делали и на серверных и на файловых много раз. Надеемся, что и дальше будет хорошо.
На одной серверной, правда, возникли проблемы - приходится сервер 1с (или sql) перегружать после такого обновления.
На других же всё в порядке.

(61) как правило, бухгалтерам надо все еще вчера. У меня недавно было 3 динамических обновления с утра до обеда. а все потому что, сдал в эксплуатацию новое закрытие месяца, у меня его успешно приняли, а как начали закрывать текущий месяц, так внезапно вспомнили про пару движений ГП, о которых они просто забыли на всех этапах. А УК надо до обеда сдаться, хоть лопни. Вот и приходится извращаться...

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

раньше (на более старых платформах) избегал ДО

(0)очень опасно, я не советую.
Не так давно объект метаданных вылетал. Пришлось напрямую в таблицах SQL ковыряться.

п1. Постройте регламент обновления на предприятии
п2. Если кто то хочет "резко" обновиться => см. п1, только в эти дни.

(0) В базе порядка 300 соединений всяких:
толстый, тонкий, web, ws, фоновые задания.
Количеством ДО в течении дня не ограничиваемся было и до 5.
2 раз были проблемы с кэшем, а в целом все в штатном порядке.

1С:Предприятие 8.2 (8.2.18.102)

Управление производственным предприятием, редакция 1.3 (1.3.39.1) (http://v8.1c.ru/enterprise/)
Copyright (С) ООО "1C", 2009-2013. Все права защищены
(http://www.1c.ru/)

пару раз косяки были, но это было давно, последнее время вроде все нормально с ДО (тьфу тьфу тьфу, тук тук тук). Удобная штука.

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

да пару раз были проблемы с кэшем. а в целом полет нормальный

(63) За такое один мой знакомый глав. бух бил бы своих подчиненных табуретом (образно выражаясь).
По крайней мере явный признак проблем в консерватории.

Если база клиент-серверная, перед демоническим обновлением делаю бэкап таблицы Config. Пару раз были сбои - откат таблицы Config приводил базу данных в рабочее состояние до обновления.

(69), проблемы есть в любой консерватории. Вопрос в количестве:)

(0) какие проблемы? одно веселье. кеш остается, потом думаешь, почему выдает ошибку на строке, которой в отладчике нет.

1с 7.7.027 2000 sql. Меняю на ходу тексты модулей, добавляю на ходу реквизиты и меняю их тип. Новые таблицы пока не добавлял, но особых проблем не вижу. Багов нет.

(73) сразу встает вопрос, когда чтото случиться, что делать знаешь?

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

(73) Да-да. Нам завидно! Но у нас кактус другого сорта.

постоянно проблемы с застреванием записей commit, при этом конфигуратор перестает пускать и приходиться ковырять в sql; УТ11 ~200пользователей 8.2.18.96