Доброго всем времени и настроения!
  Имеется тестовая база, с подключением к хранилищу. Разработка и тестирование проводится в ней, также как и проверка конечным пользователем перед внедрением в основную конфигурацию... На самом деле база не одна, их много, все лежат на удаленном сервере, к которому разработчики не имеют доступа администратора, что и правильно.
  Нам, как разработчикам ЗАПРЕЩЕНО динамическое обновление тестовых баз, под страхом казни))). Но был поздний вечер и в тестовой базе были два пользователя, которые на 98,9% просто не закрыли пользовательский режим после тестирования и спокойно спят дома....
  Я делал доработку кода в ОбщемМодуле, причем нами написанном, при этом измененный код не требует реструкторизации данных. Даже к МодулюФормы код не цепляется.. не говоря про реквизиты. Короче мне надо было срочно обновиться. Что я и сделал динамически.... За что получил "нагоняй" от нашего руководителя.... И только потому что он "подслушал" разговор с другим разработчиком про дин.обновление.
   Ну и сам вопрос: ... Чем так может замучить сервер Динамическое обновление?

(0) секта отрицателей динамического обновления. Удивительно как раздутая проблема проявляющаяся в ничтожном проценте случаев может довести до истерии.
Не суди их строго. Если ты можешь в течении пары минут вывести базу из состояния ступора после неудачного обновления то тебе "не страшен серый волк".

(0) но пока ты в этом коллективе с их правилами придется жить

(1) Как насчёт временной блокировки хранилища?

(3) + я про нулевые файлы блокировки хранилища

(3,4) не понимаю про что ты поскольку работа с хранилищем это одно а динамическое обновление это другое. Динамическое обновление можно провести независимо от того подключена у тебя база к хранилищу, аутентифицирован ли ты в нем или захвачено что-то.

а при чем тут хранилище и дин обновление базы?

(6) это к  (3) (4)

как БАЗА свзязана с ХРАНИЛИЩЕМ?

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

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

(5) я честно тоже не понимаю, может я глуп или что то не беру в расчёт...поэтому и спрашиваю

(8) Хранилище для базы одно. Понятно что есть связь между рабочим хранилищем и разработческим Разработчик захватывает нужные ему объекты из хранилища, меняет, отдает на тест заказчику и после того как заказчик принял, отпускает в основное хранилище, с которого потом и обновляются рабочие конфигурации. Вроде это просто работа с хранилищем? )))

Подниму :) Хочется и мнения другие услышать... привет мск

(14) Расширения - мовитон, а снятие проблем заключается в в снятии блокировок.... или тупого удаления нулевых lock-ов

(14) Хорошо бы если при обновлении затронуты таблицы, но если код не трогает таблицы и данные (нет добаления/удаления реквизитов и их перезаполнения и т.д.) то в чем проблема динамического ?

(14) Я не спорю, я наоборот хочу понять

(18) угу из=-за кэша все проблемы... и они иной раз такие странные и разнообразные

(18) как может пользовательский кэш на таблицу config?

+21 влиять

(18) Ваше мнение, так сказать, услышано и принято на заметку, хочется услышать и другие мнения

(19) Негатива к расширениям нет... Этот инструмент можно и нужно использовать... но только не в моей ситуации. У меня франч и только список городов, которые мы поддерживаем на несколько страниц, а в каждом городе список предприятий... и уже там список баз... и базы не типовые!!! Какое расширение? Можно ли запомнить куда какое расширение и зачем подключено?

(0) расскажи воему руководителю, что он застрял в стереотипах десятилетней давности

(18) "бывает что из -за кривого скорее всего пользовательского кэша в config попадают битые данные"

Как ты себе это представляешь?

(25) он не расскажет. Он сам в плену стереотипов, т.к. отрицает святость Расширения

точнее, даже не самого Расширения , а вот тот самый термин - хотфиксы - он топикстартеру чужд и дик.

(28) вот именно нужен хотфикс... и не знаешь как это сделать. Потому как с пользователями связывается только менеджер-консультант, а его тоже уже нет на работе. И выкинуть залипших пользователей вроде не имеешь права... Но работу надо сегодня и сейчас отпустить в хранилище, чтобы ночью обновление прошло

(29) т.е. мы знаем, что в серьезных системах для установки хотфиксов применяются hooks (крючки, крюки). Их в систему нужно вколачивать заранее. Т.е. серьезная система вольностей не прощает.
В конфигурации 1С о наличии предустановленных гибридных хуков можно узнать по модулям переопределяемый_чего_там.
А там где код абсолютно плоский - там хуже всего, но возможности вколотить хук динамически все равно остаются.
Если где в коде есть хотя бы какие-нибудь вызовы процедур или функций, то их можно использовать эти вызовы для установки хуков,
т.е. закидываешь вызовы чего попало в Расширение с пометками перед, после, вместо ...

Вроде все просто.

з.ы.
А руководитель должен не просто выдавать волшебные пендали, но и в нужном направлении это делать - под зад, но влево или прямо или вправо :-)
Но не просто сверху вниз по голове хрясь и сиди на попе ровно, никуда не двигаясь дальше.

(31) а как ты находишь якобы связь между клиентским кешем и происходящим в config?

(29) так ты же пишешь про тестовую базу. Неужели твоё руководство так опасается за тестовый стенд?

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

(34)+ причем пользователь перезаходил в базу

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

(36) совершенно не логично, чтобы 1с тащила данные из кэша на диске для сохранения конфигурации

(0) Можно 1000 раз обновиться динамически и не понять почему так на него ругаются.
А на 1001 раз поймать проблем.
До сих пор - шанс того что база будет порушена <> 0.
А это время на восстановление и прочее.
Или будут какие нибудь экзотические проблемы, например отвал отладки - в 8.3.16, 17 - неоднократно ловил на тестовой. Лечится или чисткой кеша или полные логаут из системы - а это всё время.
Задача руководителя одна из - обеспечить беспередойное функционирование.
Динамическое обновление по разным причинам может этому помешать.
Банальный отрост таблицы config раком может нагнуть SQL сервер, и страдать будут все из-за одного.

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

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

(40) адекватные, это которые на предложение перезапуска ДА отвечают ? :)

(41) именно и в добавок не оставляют открытые сесии на ночь :)

вообще в случае (0) надо было через консоль выкинуть тех двоих и спокойно обновить

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

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

(44) есть ряд работников которые часто перерабатывают и продажники часто из таких. Имхо, достаточно регламентировать ежедневные тех.окна. Всех кто не вышел - выносить из базы ибо регламент есть регламент

(0) Можно ж было просто добавить произвольный объект и обновить с выкидышем пользователей.

(42) Это самое оптимальное. Плачут и не понимают, что произошло только двое. А при проблемах динамическое - плачет большинство.

(0)Был случай на 8.1, может уже исправили и такое не может больше произойти, а может и нет. Баз РИБ, были проведено обновление конфигурации динамически на всех пяти базах. Обновили и продолжили работать. Где-то через неделю обнаружили что в одной из баз, не хватает куска кода, в остальных все ок. Этот модуль не трогали очень давно. При этом обмены обходят и 1С считает базы идентичными. Было не очень приятно и немного тревожно) кабы чего не вышло, что еще похерилось о чем я не узнал?

Странно, что у разработчиков нет возможности "выкидывать" пользователей из тестовой базы. Хотя бы по регламенту.

(30) В смысле "волшебных пендалей" у нас всё ровно. Есть ещё и "волшебные пряники". Пенделя дают ему, руководителю моему, а он не программист, консультант. А он пендель передаёт по цепочке.
   Отсюда в принципе и вопрос и сама ветка. Хочется умных мыслей, что дин.обновление не так уж и плохо при умном использовании. А просто "не делай так, потому что так нельзя, а нельзя однозначно и без объяснений" - это тупо.

(33) Разговор о том, что после динамических обновлений у клиента падает сервер. Не база! , проблемы на сервере мне не понятные. Я же не эксперт по хехнологической части )))

(51) можно долго долго разбираться с этими всеми тонкостями... Дам изложение своими словами.

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

Механизм Расширений игнорирует наличие кэша конфигурации. По всей видимости, было сделано предположение, что объем дописок в Расширениях относительно небольшой, а потому взамен кэша возможно считывание Расширения прямо и непосредственно из того, что сохранено в базу (т.е. Расширение работает без кэша - это мое предположение и упрощение)

Более того, взаимодействие Расширения с платформой несколько отличается от поведения просто Конфигурации с платформой, особенно, когда работает все в режиме 1С Клиент-Сервер. В файловой не так, а по своему, но все равно не так, как у конфигурации без расширения.

В результате имеем несколько другое поведение, скажем так, платформы и сервера платформы в процессе работы с базой.

Обращаю внимание, что о наличии кэша на клиенте обычно помнят все, а вот, что он есть и на _сервере_ - забывают

Массовые проблемы с кэшем при динамическом обновлении были ещё на 8.1. Уже на 8.2 их количество резко уменьшилось. А на последних версиях платформы это вообще экзотика

+ самые проблемы с дин. обновлением были на файловых базах, клиент-серверные меньше спотыкались

(55) А у меня наоборот.. На файловых ни разу. На серверных встречалось

(52) Надеюсь разработчики 1С прочитают твои мысли.... Нужно же им что то читать на досуге. И сделают верные выводы

(53) Кэш хранится в 3 (трёх!) местах

(58) но это же разный кэш :-)

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

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

Тебя посадят, а ты не воруй (с)
Базы рухнут, а ты не динамь