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

Так задумано. Обновись 1 раз нединамически, в следующие разы все будет ок.

динамическое обновление все еще зло

(1) Спс. Так и сделал... т.е. дальше проблем не будет!?

(3) будут, обязательно будут. Если часто обновлять динамически, то один раз попадёшь

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

Вообще при грамотно организованной работе по разработке и поддержке динамическое обновление не требуется в принципе. Оно может понадобиться гаввнокодерам с их экстремальным программированием.

(6) Есть теория, что иногда нет других вариантов, типа работа 24/7.
Хотя, имхо, всегда есть вохможность установить технологические паузы для обслуживания базы.

(7) не бывает 24/7 относительно 1с. Все можно сделать паузу

Нуф-Нуф категоричен

Один раз - не быдлокодер

(9) давай аргументы против

Нуф-Нуф гонщик.

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


пример: 24/7, 20 человек сидят чо то делают, кто то обедать ушел кто то уснул, кто то на мисте мистит.. ну в общем работа кипит
а тут бац и надо побыстром что то подправить.
подправил и пошел, бекап просто сделал скулем перед обновлением на всякий случай и все.

а если всех ждать, всех просить выйти то до вечера ничего никуда не обновишь.


особенно когда в конторе работают всякие ночные смены которым ночью хер дозвонишся чтобы они сами добровольно вышли.

(12) ключевое "а тут бац и надо побыстром что то подправить."
Это и есть гаввнокодерство. См(6)

(12) Выгнать не проблема. Главное, чтобы было согласовано релизное окно и в SLA было прописана возможность внеплановых срочных обновлений.
А если SLA нет, то тем более - всех предупредил, и кто не спрятался, я не виноват... :)

(13) только молодые да ранние столь категоричны в суждениях...

простой пример: v8: БП2. Закрытие месяца. Расчет налога на прибыль

(13) а вообще, динамическое обновление не дураки придумали и не просто так..

просто тупари им пользоваться не умеют...

(15) хз такая категоричность появилась после участия в серьезных проектах с серьезными специалистами.

И че там по ссылке?

(17) пил кофе в одном помещении с серьезными дядьками? :)
тебя окатило сиянием их серьезности?
проникся?


зы: в декабре на конференции задам вопрос разработчикам, почему они не уберут динамическое обновление из платформы если все серьезные специалисты считают что динамическое обновление зло...

я бы даже добавил к (17) что до такой категоричности еще нужно дорасти

(19) да да.. это типа как MSSQL и базы с полной моделью восстановления и несжатым логом.

точно.. можно категорично утверждать что фул не нужен а нужен симпл и шринк..
ага..

и везде это пропихивать, ибо раз сам не пользуешься значит ненужно :)

(20) странное сравнение.

читаем (6) до просветления

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

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

(22)Это идеальный случай не достижимый в большинстве случаев.

(23) что бывает в рабочем процессе?

(24) ооо... постепенно таки идем к истине... "разработчики пишут без ошибок"...

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

спорить тут бесполезно. гаввнокодер найдет 100500 оправданий почему он гаввнокодит

(22) Глупень. Не понимаешь разницы между " работой по разработке" и реальным, млять, магазином. С кучей кассиров, толпой на кассах, злобной главбушкой, зашуганным материально ответственным товароведом и гендиректором с дыркой в голове. Который каждый его "выпил" из программы воспринимает, как личное оскорбление.
И когда у тебя таких магазинов штук 15...
А что касается разработки, то да, соглашусь. Для разработки динамическое обновление действительно ненужно.

А интересно, Нуф - единорог? Или просто какает радугами? :-))

(28) А еще некоторые торгуют из 1с. Представьте себе, есть такие отчаянные люди....

(29) а зачем выгонять пользователей в течение рабочего дня? тем более в таком количестве?

(32) А некоторые еще и круглосуточно торгуют...

(33) ну и что это значит? даже нет шанса обновиться на новый релиз?

(33) см (8)

http://img6.joyreactor.cc/pics/post/философия-жизнь-456896.jpeg

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

(26) я выше приводил ссылку.
100% типовая БП.
закрытие месяца
10 человек  в базе и никто не будет никуда выходить ибо нет времени да собрать всех в один момент нельзя.

а ошибку исправлять надо.


ваши дейстия?

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

вы будете что делать?
всех обзванивать чтобы вышли?
а если там филиал и они обедать отошли? или еще что?

(37) давай приведи пример торговли, когда остановка продажи на 5 минут в 2 часа ночи приведет к  потери кучи бабла

(39) а пусть это будет не 2 часа ночи а 15 часов дня?

Поэтому для глобальных обновлений нужно тщательно выбирать время, когда меньше всего загрузка. А для мелких доработок вполне годится ДО.
Чтоб мне не в ночь с воскресенья на понедельник в печформе два слова добавлять.

(38) зачем обновлять на новый релиз в 15 часов дня, когда это может привести к остановке продажи и потери кучи бабла?

+(41) тем более что это надо сдесь и сейчас :)
а не в понедельник с утра :)

(39) Легко, единые информационные базы где магазины и склады в одной ИБ, а ночью идет интенсивная погрузка и вот кровь из носа нужно чтобы на 50 машин постоянно печатались документы.

Да идите вы к аллаху и Морготу, в 2 часа ночи базу обновлять...

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

(39) Объясняю. Остановка в 2 часа ночи на 5 минут приведет к потере кучи бабла, потому что я его возьму за то, что мне надо подрываться в 2 ночи и пилить какие-то обновления.

Я за ночную работу двойной-тройной ценник выставляю, ибо нефиг.

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


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


ваши действия?
неотправлять отчеты?

(41) зачем делать мелкие доработки через ДО, когда можно из накопить и обновить все одним релизом?

(44) О! Сразу видно, человек 1с не в кабинетах разработчиков изучал )))))))))))

(46) давай давай..

к тебе в 16:30 прибегает главбух с вытаращенными глазами  и говорит что у нее "прыбыль вся слетела" а сегодня последний день

а ты ее пошлешь по регламенту? %)

(49) А затем, что мелкая доработка иногда стоит кучу бабла.

(49) вот вот, см (48)
тебе - незачем

(44) проблема в архитектуре, в организации труда и голове

(52) пример?

(48) см (46)

(49) Потому что иногда бывает нужно СРОЧНО. Заканчивается банковский день, последний день сдачи отчетности, пришел разъяренный ключевой клиент, гендир требует странного и вот прям чтоб сейчас...
Гражданин, а вы на реальных предприятиях работали вообще? )))

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

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

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

(57) давай пример срочного

(56) какой реглмент в чрезвычаной и нештатной ситуации?
кто будет ждать когда пользователь из филиала вернется с обеда/перекура и соизволит выйти из базы?

(60) см (15)

(61) мсье не умеет навыков оповещения и отключения пользователей?

Нуф-Нуф,сегодня выступаешь в роли общественного раздражителя?:)
Все-таки демоническое обновление-это штатный режим работы 1с,а значит он не должен противоречить правильной теории разработки

(54) Какая фийеричная отмазка :)

(62) на это я уже ответил

(60) Хм... "банковский день", видимо, термин вам незнакомый... И что бывает за неуплату нгалога или штрафа в срок вы тоже не знаете?
Тогда для вас - ничего срочного. Рисуйте свои сферические регламенты в вакууме, о применении их в реальных боевых условиях доложите отдельно.

(64) правильная теория разработки не подразумевает "срочного обновления". это нештатная ситуация и признак гаввнокодерства

(63) платформа не умеет :)
а тонкие клиенты суки такие еще и мгновенно восстанавливают подключение если их сбросить принудительно

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

(67) какой-то банковский день... какой-то штраф... ты живой пример давай а не фантазируй

(66) а какого черта подолжаешь спрашивать бесконечно "хотя бы один пример срочной ситуации" ? :)

(69) ты когданибудь пользовался сервером предприятия?

(70) бгыы ну вот опять, я в (15) дал живой пример - живее некуда.

и это я еще не рассматриваю варианты когда в последние дни сидят главбухи и решают КАК ИМЕННО они должны закрывать месяц ибо у них на руках 100500 предписаний аудиторов и учет наглухо нестандартный...

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

(72) ты когда нибудь оказывался в ситуации когда у тебя к кластеру серверов нет доступа? :)

видимо нет.. ибо фикси привык сидеть на попе ровно, жить по регламенту и никуда не спешить :)

(73) а что это за такие варианты?

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

(75) какой такой случай когда не доступа? :)))))

(77) давай пример твоей галочки, которая "нужна, хоть умри, но прямо сейчас"

(75) как раз фикси и рвёт анус себе и другим, это франчи по регламенту живут :)

вы одолели своими сферическими конями в вакууме. давайте конкретику

(78) у меня у половины клиентов админы закакимтохером залочили доступ к консоли сервера предприятия..

и чо теперь?

(81) я тебе привёл пример из реальной жизни, случившийся у меня месяц назад. Ты его проигнорил. Что тебе ещё надо?

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

(76) ну из недавнего: распределение ндс по прямым затратам.
вот такие были предписания аудиторов.
типовая умеет по косвенным.
надо - по прямым.

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


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

(83) извини, пропустил.

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

(81) Да какая тебе конкретика нужна?
Предприятие работающее круглосуточно и интенсивно, мелкие обновления в любом случае будут предпочтительней динамически

(84) клиент то как раз заинтересован в скорейшем решении своих проблем.

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

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

(70) Это живой пример. За 10 минут до окончания опердня дня позвонила главбух и сказала, что не может отправить штраф по клиент-банку. Мера пресечения - вплоть до ареста счетов.
Еще было дело, когда проверка РАР заявила, что в магазине неправильно оформляют некий документ и предложила до вечера перепечатать 500 штук. Мера пресечения - закрытие магазина на лопату.
Если это не срочно, то уж не знаю, что для вас срочно.

Как вам тезис: не ошибается тот,кто ничего не делает?
Не бывает в жизни ситуаций,когда все можно предусмотреть.Вот у тебя в SLA написано,что в такие-то дни имеешь полное право отключать от работы пользователей на такое-то время.А потом БАЦ и ошибся ВСЕГО один раз.И что,ждать следующего окна из принципа???

(87) приведи пример, когда необходимы мелкие динамические обновления?

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


вот именно конкретный жизненный пример имел место быть 20 дней назад.

и что делать? отправлять их писать ТЗ ? :):) :)

(92) да например при сдаче отчетности туева хуча мелких ошибочек частенько бывает

(92) Да хотя-бы обновление прав для новых пользователей. Ввели новую должность, для них новый набор прав и ролей. Что мне предприятие с 300 пользователей, 100 из которых круглосуточные останавливать?

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

резко и внезапно поправить права определенной роли.

внести изменения в общую функцию формирования номеров документов.


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

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

что значит неверно оформляется документ? какая ошибка была в 1с, которая не позволяла верно напечатать документ?

+(95) а пользователь завсегда в процессе реальной работы найдет что то что он же пропустил во время тестирования но без чего работа невозможна в принципе и все предприятие можно смело банкротить закрывать а персонал расстреливать :)

(92) Вы ударились в демагогию. АБСОЛЮТНОЙ необходимости в ДО, разумеется, нет. Мы все на 7-ке сидели и ничего, разгоняли народ из баз, как миленьких.
Но вы продвигаете тезис о том, что ДО - реальное зло, которого нужно избегать ЛЮБОЙ ЦЕНОЙ. А не могли бы обосновать - почему? Чем оно такое ужасное?

(97) такая ошибка.. какаято..

тебе все решенные проблемы за последний год перечислить? :)

(95) у вас каждый день добавляется новая должность с новым набором прав?

100

(101) нет но если она добавилась и что то пропустили во время тестирования то...

опять же никто не говорит что ДО надо делать КАЖДЫЙ ДЕНЬ и ОБЯЗАТЕЛЬНО :)

В проектах, х***тах. Приходит начальник и грит впили мне такую плюшку минут за 15, срочно нужна.

Да у вас тут холивар )))) Впринципе Нуф-Нуф прав - если серьезно работать, то надо сразу закладывать все доработки, обновления и при хорошем тестировнии ошибок будет минимум - так допустим работает одна из наших компаний на САП - у них даже годовой план на разработку есть. НО! Это в идеале, иногда очень удобно исправить одну мелочь (твой это косяк или же франчей), которая мешает жить одному пользователю с его важным отчетом (ему надо пипец как срочно) и при этом не гасить работу 300 пользователей в день закрытия, когда счет идет на часы и минуты - у нас трогое закрытие по часам присылается из СШП.

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

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

(104) будь мужиком, ткни его носом в регламент и шли лесом - у тебя обновления в воскресенье в 2 часа ночи и не ипет.. до воскресенья ты совершенно свободен :)

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

(104) да конечно, а если он тебя отсосать попросит?

(107) идиот старший менеджер достал уже главбуха путать склады отгрузки.

так достал что уже у главбуха истерика.

всякие "я больше никогда путать не буду" уже проходили.

приняли волевое решение: заблокировать поле и сделать автозаполнение срочно и сейчас пока кого то не убили нах.й...

(110) не, он просто попросит собрать свои вещи и идти на.. в отдел кадров за расчетом )))

(110) Насчёт отсосать - кто там у нас мастер на кожаной флейте? :-))

(111) несерьезно

(107) Потому что он именно сейчас накосячил, и директор поднял по этому поводу волну с требованием "немедленно принять меры!".
Вы вообще работали где-нибудь?

(110) точно ведь подмечено,

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

ну чтобы самый главный начальник знал кто в конторе хозяин..

(110) Аргументы не связанные с твоей любимой дудкой кончились?

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

в реальном мире 100500 раз подобное встречал.

А по что Мазилла не в бане?

а по поводу "все работали на 7ках" - ага..

то то модули во внешних текстовых хранили, а потом еще и ныли пару лет "какова черта в 8ки этого нет" :)

помню помню...

Очень интересная ветка. Внесу свой вклад, а то НуФ-Нуф успокаиваться начал))
Если есть возможность использовать динамическое обновление, то его нужно использовать.

а вообще, утверждать что штатная функция невообразимое зло на основании того что сам напоролся на косяк это тоже самое что утверждать что работа 1с с постгре невообразимое зло ибо сам его настроить не смог..

Нуф-Нуф, а все-таки, как насчет того, чтобы обосновать вредность ДО? Ну, конечно, кроме того, что так "большой дядя" сказал.
Давайте проверим, как вы знаете 1с. Как вы разбираетесь в рабочем процессе, мы уже выяснили.

ГОСПОДА. Благодарю за участие в такой увлекательной беседе с довольно интересным результатом, который можно охарактеризовать как "ЧТО И ТРЕБОВАЛОСЬ ДОКАЗАТЬ".
В начале ветки я высказал мысль (6)(8)(28) что необходимость динамического обновления - это признак плохой организации работы. и что гаввнокодеры будут всеми правдами и не правдами оправдывать свое гаввнокодерство.
Не было ни одного адекватного примера, когда потребовалось бы динамическое обновление при грамотно организованном процессе разработки и сопровождения. Единственный пример был в (15), но он был дискредитирован в (85).

Все же остальные - это были просто попытки нарисовать сферического коня в вакууме.

(122) вот-вот, штатная, в принципе и при обычном обновлении накосячить можно только в путь

Нуф слился. Что и следовало ожидать.

Нуф уже не торт

я похоже опять пропустил твой ответ на (86)?

Стоило только попросить рассказать про 1с-ку чуть более подробно. Чего и следовало ожидать.

Зато... какой студенческий энтузиазм

(124) Кодеры не всегда виноваты в гамнокоде, их нередко заставляют гамнокодить по криво поставленным ТЗ, потом спешно исправлять

(64) Ручные коррекции (например, ручные выравнивающие операции). Внешние обработки. Внешние печатные формы.
Это позволяет, имхо, закрыть 90% сбойных ситуаций как временное решение, чтобы заткнуть дыру сейчас, а потом планово обновиться.
+ 5% случаев, когда косяк приводит к глобальной неработоспособности 1с. Но это ошибки тестирования.
Имхо, так.

Интересно, когда НУФ-НУФ столкнется с необходимостью ДО в работе, он вспомнит свои слова?

(124) ну во первых (85) не связан никак с (15)
а во вторых: что именно тебя смущает в (85) ?

(131) если кодер не гамнокодер - он увидит кривость, оповестит об этом разработчика ТЗ, попросит внести корректировки, и тем самым снимет с себя ответственность

франчи не будут использовать ВПФ и обработки - мозгов не хватит. им проще накидать гумна сразу в конфу и обновить демонически.

(128) Ой. Стойте, гражданин, не уходите.
Расскажите мне как технический специалист техническому специалисту, что именно неправильно в механизме динамического обновления от 1с, и почему я должна оказать главбуху в добавлении пары строчек в печформу, если он хочет срочно, у меня есть на это время и никакие религиозные и моральные принципы мне в этом не препятствуют?

(134) см (89) :)

(136) перепиши закрытие месяца в внешнюю печатную форму

(99) Вот когда из-за непочищенного кэша вы при закрытии "банковского опер дня" влетите на пару лямов. Тогда и поговорим :)

(139) ага.
срочно и за 15 минут :))))

(138) никогда ТЗ сам не разрабатывал?
не тестировал?
не отлаживал?
не находил уже в отлаженом и оттестированом неучтенные при разработке ситуации?


смешной ты.. на основании ОТСУТСТВИЯ опыта строишь суждения :)

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

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

(141) ага.. в последний день сдачи отчетности.. когда уже 15:00 и все пьют валерьянку :)

И все же.
Мне интересно, как программисту - ЧТО именно не так с ДО? Кто-нибудь может КВАЛИФИЦИРОВАННО разъяснить мне все его ужасы? Именно с точки зрения технической реализации данной функции?

(135) Кодера просто пошлют лесом и заставят сделать срочно. Это во первых, во вторых ТЗ может быть нормальным, но не полным и кодер этого уже может не видеть

(143) знаем знаем, теоретически можно все отчеты сдать в екселе и никакие 1С не нужны..

(148) есть вариант гораздо проще... внести изменения в копию и перенести результат в основную ИБ

(146) забей, кроме Одна Бабка Сказала нет никакой информации.
у нуфнуфа сработал синдром утенка.. вот он и уперся :)

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

(142) ладно. откуда в (85) тз? вы чего-то разработали. накатили на рабочую. поиграли. опять разработали и накатили, опять поиграли.
большая проблема сделать это на копии и протестировать?

(146) дело не ДО. дело в головах

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

заманаешься отслеживать что ты перенес а что еще нет..


а так да.. в теории все красиво... как и нуфнуфа с его регламентами

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

(146) v8: НЕ динамическое обновление и локальный кеш

(154) почему в теории, у меня типовая УПП на крупном заводе. работаем с 2006 года, все ОК.

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

(137) Внешняя печатная форма.

Для тех кто не понял. Проблема не в ДО. А проблема в ВАС. Использование ДО - это лишь сигнал о том, что в консерватории что-то не то

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

но это не значит что аварий не существует и пристегиваться не надо :)

(158) ты с какими тз работал, с одностраничными и сроком реализации в 1 день?

НУФ НУФ не из франча случайно? Или это на фикси обсуждается с заказчиком ТЗ?

фигасе вы с утра замутили
ставлю пару монет на Нуф-Нуфа
тк ДО действительно от лукавого

(160) проблема не в ремнях беопасности, проблема в вас.
при грамотном вождении ремни безопасности равно как и подушки - ненужны..

если вам нужны ремни и подушки то это сигнал что в консерватории что то не то..


ага...

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

(162) а все ТЗ должны быть на 100500 страниц и сроком реализации на полгода?

(163) на фикси не бывает ТЗ. мсье кодит только в экстремальном режиме?

(165) чет походу в лужу пукнул...

Ну и что может франч рассказать про необходимость ДО? Смешно.

(169) да нет, нормальный пример.

(168) лолшто?

Периодически использую, даже при условии не круглосуточной работы предприятия. Да, есть 4-6 часов в сутки, когда есть монопольный доступ, но я в это время предпочитаю спать, а не добавлять новую роль в базу. Бекапы делаются. За 5 лет попал один раз на необновление кеша, пользы от ДО получил больше.

(172) глупый чоли?

ТЗ это пачка листов на первом из которых должно быть написано:


Техническое Задание

дата номер версия сроки исполнители и тд и тп..


все остальное - это не тз :)

(172) лоллол. Бывает, причем довольно хорошего качества порой.
Кстати, где все же работает месье? Я что-то затрудняюсь определить это по его ответам. Он столько всего не знает )))

(175) В стале - литейном цехе :)

(174) Мне на фикси и такое попадалось. Делала отчетность поставщикам, так оне такое ТЗ и высылают. По всей стране всем одинаковое. Прям на нем так и написано: ТЗ, я не вру, чесслово.

(173) + 1 Конечно, можно и магаз остановить, и покупашек разогнать и гендира накуй послать.
Вопрос только - ЗАЧЕМ?

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

а я знаю примеры когда из за тупорылых 1Сников блокировалась нормальная работа отделов ибо они, тупорылые 1Сники, требовали  ТЗ по хитровыепаной форме которую самостоятельно ни один пользователь не мог написать..
ибо "наадо работать по регламенту"

результат: тупорылые 1Сники там уже не работают...

(179) житейских вариантов море.
но согласись - есть ситуации когда надо:

- прямо сейчас
- срочно
- в рабочую

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

(182) там два варианта:

либо товарищи фикси и никуда не торопятся
либо жадные товарищи работают "по часам" и чем больше часов тем больше бабла


:)

(181) бывает. если прямо сейчас и срочно - значит руководителю нужно. значит выкидываем всех уборщиц-менеджеров из базы и спокойно обновляем.

В споре рождается истина(c)Сократ.
Мне кажется, что каждый останется при своем мнении.

(184) ну так динамическое если надо выкинет..
просто пока ВСЕХ уборщиц выкинешь - уже не получается "прямо сейчас и срочно"
а получается "через час а может через два"

(184) А зачем? Пусть работают. И уборщицы и продавцы. Если можно без этого обойтись, то так же лучше будет, не?

(186) час? это если 1000 пользователей в базе и каждого отдельно отстреливать?

(186) И самое главное - ЗАЧЕМ? )))))) Пусть люди трудятся, деньги зарабатывают.

нее что значит пусть работают

нифига

пусть уважают мою власть
знают кто базе хозяин

захотел- выкинул всех на полчаса и пофиг что отгрузки стоят и клиенты заказ надиктовывали по телефону на полуслове прервались и надо все заново надиктовывать..

10099854  Сеанс отсутствует или удален

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

Дата публикации:
2012-03-29

10096672  Попытка получения неинициализированного значения параметра сеанса

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

Дата публикации:
2012-01-19

10081327  Соединения конфигуратора в консоли кластера

Проблема:
При последовательных динамических обновлениях конфигурации с перезапуском конфигуратора в консоли кластера серверов добавляется множество соединений с Конфигуратором.
Дата публикации:
2011-05-25

10095297  Динамическое обновление

Проблема:
После нескольких динамических обновлений может проявляться нестабильная работа конфигурации - пользователи могут работать с неактуальными текстами программных модулей.
Способ обхода:
Очистить кэш метаданных.
Дата публикации:
2011-12-07

10095353  Сеанс отсутствует или удален

Проблема:
В клиент-серверном варианте информационной базы после динамического обновления конфигурации в веб и тонких клиентах, соединенных с информационной базой по http, может происходить ошибка
Сеанс отсутствует или удален
и аварийное завершение работы.
Дата публикации:
2011-12-07

10041697  Динамическое обновлении конфигурации и управляемые блокировки
Проблема:
При динамическом обновлении управляемые блокировки остаются в состоянии, из которого нельзя их вывести.
Способ обхода:
Не использовать динамическое обновление.
Дата публикации: 2010-05-13

http://cs309218.userapi.com/v309218352/47b7/TGZpZfWbujQ.jpg

(41) Открой для себя внешние печатные формы ;)

(190) у нас отгрузки не стоят. делают во второй базе, я потом переношу все что набили.

(188) это если сидит 10 менеджеров и у каждого из них заказы по десятку другому строк заполняются..

а еще пара бухгалтеров один из которых месяц закрывает другой книги формирует

а еще кладовщик который инвентаризацию делает.. и у него ведомость открыта и он ее заполняет

(190) Главное, чтобы кэш цел остался!!!! Что перед этим какие-то продажи? )))))

(194) прибить сеанс и пофигу кто там что заполняет

(47) Такой неграмотный - и туда же, кучу бабла требует... открой для себя пакетный режим.

(193) никто не говорит что надо демонически обновлять базу на 100 гигов объемом и 100500 человек онлайн пользователей.

тут то как раз нужен индивидуальный подход.

но мелкую базу на 20-30 пользователей да которые постоянно чо то там колотят - вот ее обновлять демонически как раз часто и приходится.


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

(196) да да.. см (198)

200

(51) Померь мне, если все так серьезно - она сама скажет рубить всех и делать обычное обновление. Чтобы без риска.

P.S. Представь - ты сделал ДО, а база рассыпалась. Лучше ей будет?

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

и пару раз вот так вот такой звезде грохни ее любовно набиваемый заказ на 100500 строк где она с заказчиком по каждой строке уже 2 часа торговалась про откаты и прочие скидки...

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

(197) Пакетный режим умеет вносить изменения в печформы? О майнготт, ухожу из профессии.

(201) Для этого делают люди бекапы.

(203) вообще-то умеет.... /UpdateDBCfg

(201) а вот для этого я делаю полный бекап скулем прежде чем демонически обновлять.

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

так что для меня выгода есть..

Нуф-Нуф - мои "пять с плюсом". Нелегко быть защитником дьявола :)

(202)+100500 все так!

(205) И документы перепроводить умеет? )))

(209) да, если специально обучить

(209) Разумеется. Автоматически менять реквизиты после обновления она умеет, значит, сумеет и документы провести.

(82) Ну дык даешь задание админу выбросить всех пользователей и залочить вход. Чо как ребенок?

(202) Ещё может быть интересный нюанс - ночью, к примеру, в 1с могут работать таджики:):) Они по-русски вообще плохо понимают, но приучены нажимать на нужные кнопки:) У них шаг вправо, шаг влево - все, катастрофа.

(212) А вот есть масса. Просто масса контор, где админ - приходящий.

(212) ты этого админа найди еще :)

дозвонись..
он удаленно подключится
залочит и тд..

как раз пара часов и пройдет.

об чем и речь.
а надо "уже джва часа назад как должно было быть сделано ща все прогорим мать вашу"

(88) Угу, видать у вас ларьки на обслуживании. Ни разу не было такого, что восстановление из бэкапа 3-4 часа идет?

(183) Здесь просто другой вопрос. Надежность (стабильность работы рабочей базы) иногда важнее скорости изменения.
+ при реализации надо сразу учитывать, что потребуется запускать в авральном режиме испраленную версию. (например, по возможности весь изменный функционал имет не в общих модулях, а в обработках. Тогда никаких проблем с запуском измененной версии. И это будет даже быстрее, чем динамическое обновление.

Что надежнее и быстрее - динамически обновить базу и почистить кэши или запустить измененную внешнюю обработку?

(216) Средствами SQL-я???? Нет, самая большая база ок 5 минут навяливается.

(213) именно...
пацаны не сталкивались с ситуацией когда на утро 1Снику выкатвыают предъяву на тему "предприятие не работало всю ночь потому что 1С не работала"

а то что 1С выключилась на 20 минут а потом включилась ибо 1Сник обновлял - никого не колышит.
выключилась, через минуту не включилась - работники ушли спать с чистой совестью :)

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

(217) Обработка вам запись в регистр не сделает. Хоть убейтесь, а извольте документ слепить.

(219) почему, сталкивались. отключили электричество - сервак выключился. один эс не работала.
предъявы конечно прогеру :)

Бить или не бить? Вот в чём вопрос!
Оставьте Нуф-Нуфу нуфнуфово и пользуйтесь в своё удовольствие демоническим обновлением. В чём радость доказывать упёртому что-либо? Только потому, что он назвал вас земляными червяками? )))

(95) Сделай 1 раз роль с настройкой из режима Предприятия - и забудь про этот головняк. А так - просто даешь ему роль, где нужный доступ есть, а в регламентное время обновления вносишь изменения по конкретной роли под пользователя (хотя это тоже не айс).

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

(219) при работающем электричестве, сервере и интернете :)

(219) И причем тут 1С и демоническое обновление? Вам уже ничего не поможет - бегите от туда :)

(216) никто и не говорит про базы в 100500 гигабайт..
тут речь про небольшие конторы и небольшие базы

+

все же восстановление скулем из полного бекапа 4 часа.. это какой же объем базы и где лежит бекап?

вы его чтоли по сети через 3г качаете чтоли?

У меня бекап 80 гиговой базы разворачивается около 5 минут. Что я делаю не так?

(226) зачем.. контора платит, вовремя, исправно и хорошо.

зачем мне бежать оттуда?

да, там 24/7
да, там таджики ночью, звезды днем и истеричные главбухи
да, я там демонически удаленно обновляю

но деньги не пахнут...
их деньги ничем не хуже тех денег что заплатят в другой конторе

(228) надо делать так:

1. бекап положить на ноутбук
2. ноутбуком подключиться в интернет через 3г модем
3. войти в впн сеть
4. расшарить бекап общей папкой с ноутбука
5. восстанавливать базу указав на сервере путь к этой общей папке
6. включить таймер и счетчик бабла 1ч=2500 р.
7. включить пару фильмов..
8. профит!!!

+(229) кстати тяжелые обновления я согласовываю с ними за неделю, и еще за день уточняю чтобы не забыли - они тогда на период обновления производственные задания печатают и работают "по бумаге"

(228) наверное гигабайты с мегабайтами перепутаны :)

(219) Ну что сказать... Ты знаешь специфику:)..
(226) В таких конторах иногда(поначалу) могу попытаться набить морду 1с-нику:) Там народ простой. При общении с конторами 24/7 1с-ник должен быть готов, что людям ночью при неработающем сервере и опаздывающей отгрузке срывает башню. Приходится себя ставить в коллективе:)

(165) Если тебе регулярно требуются ремни и подушки - то действительно что-то не то в консерватории...

(204) Ошибка связанная с динамическим обновлением может обнаружиться через несколько дней. Никакие бэкапы не спасут. Засада именно в этом - пользователь работает с неактуальной версией.

(220) Если ошибка при проведении документа - обработка может ему нарисовать нужные движения. Если ошибка при записи (создании) документа - бейте по рукам разработчикам и тестерам. Табурет могу одолжить.

+235 Но конторы бывают разные. И соглашусь с тем, что многда легче срубить бабла на динамическом обновлении, чем убедить заказчика, что надо что-то изменить в консерватории.
Каждый сам выбирает.

(235) А если нужны движения, которые не предусмотрены конфигурацией?
(232) Это, видимо, ты перепутал бекапы SQL c бекапами 1с.

(235) см (15) иди набей руки разработчикам и тестерам.. ага..

интересно, а я смогу сдать экзамен по троллингу?

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

смотря кто в комиссии будет

ДО - очень удобно, но к сожалению при частом ДО возникают непонятные ошибки в текущей работе: сеансы отваливаются, аварийное завершение работы клиентов, зависание рабочих процессов на сервере.
После запрета ДО на рабочих базах стабильность работы 1С повысилась в разы.
P.S. До сих пор завидую Аксаптерам которые могут менять структуру базы, коды модулей, формы не только без монопольного режима но вообще не закрывая клиента - достаточно переоткрыть форму.

(эссе на тему)

Хмм... у тех, у кого нет риб-базы - меня им не понять.

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

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

Эхх, не понять им моих проблем...

(234) а никто "сложные" случаи тут не рассматривает..

базу в 600 гигов и 100500 юзверей динамически тоже никто не предлагает обновлять.

мы тут в основном о ларьках и прочих нищебродах..

Вывод: использовать ДО можно, даже нужно. Но в небольших количествах и тщательно предохраняясь.

а кто то же скажет что секс это плохо ибо может быть спид сифилис или даже беременность :)

но ведь все понимают что если предохраняться то секс очень даже ничего..

(246) передразнивая:

Вывод: здесь не обсуждаю вопрос "Что делать, как быть?", а только - "Бить или не бить" / "Делать или не делать".

Фи, мне противна ваша черно-белая логика.

(248) ну так тут нуфнуфычу то и пытаются объяснить что мир не чернобел
и есть дофига ситуаций когда ДО нужно ибо без него уже никак..

Девиз к демоническому обновлению должен быть - "Можно... но осторожно"(с)

PS: а вот то, что этот "штатный инструмент" подобен троянскому коню - никто не оспорит. Имхо! и эта тема - тому подтверждение.

(242) к этому все идет

(215) Зато ты после такого получишь доступ к серверам предприятия. А виноватым окажется админ ;)

(218) Ну значит вы просто еще не доросли до того, о чем говорит Нуф-Нуф Он, конечно, немного перегибает, но более 99% исправлений вполне можно внести обычным обновлением, в запланированные сроки. А динамическое использовать раз в несколько месяцев по особым случаям.

(227) Ну дык гигов 300-500 база. Полный бэкап перед динамическим делать - это на час-полтора. Так что восстанавливать приходится не из полного, а с журналом транзакций. Вот на это время и уходит.

(228) Приукрашиваешь. 270 Мб/с реальная средняя скорость записи (а ведь еще и читать надо откуда-то) - такое железо под 80 Гб базу покупать не будут. Скорее всего у вас там из 80 Гб занято реально горзадо меньше, просто сразу базу создали с запасом по размеру.

(237) Пишешь обработку, которая делает нужные движения документу.

(243) И что, узлы после ДО не отваливаются? Значит, врут люди?

(252) бгыыыы

пришел водитель белаза учить правильному шинмонтажу с участием подъемного крана и прочих спецбригад..

ничего что тут мы на матизах?

IamAlexy, Нуф-Нуф хотел сказать, что нужно разделять божий дар и яичницу.

В реале, не все ситуации "требуют" демона. Далеко не все. Чаще всего - от неорганизованности. Прогера или юзверей - не уточняю.

Регламент - не есть зло, если он в умеренных дозах.

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

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

(254) ты местами перепутал ники в своем посте :)

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

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

(255) Попрашу вас не ругаться в моем присутствии непонятными словами.

(256) Ничего я не "перепутал" :( Он требовал озвучить ситуацию, которую без демонического обновления - не разрулить. И никто не озвучил таковую поего (и моему) мнению.

(258) Ишь ты, демоническое обновление и на коде сказывается ?
Нуф-Нуф демонически обновил конфу, чтобы не ждать обеда и ушел сдавать экзамены на троля, а ветка живет ;)

Красава

(259) я озвучил в (15) да и еще много раз примеры приводил..
просто вы не хотите читать и не вникаете в ситуации..

примерно как "приведите мне пример где нужен автомобиль и нельзя пешком дойти"

У меня в понедельник как раз случай был показательный. Делали доработку УТ по ТЗ. Протестировали сами, 5 ноября отдали клиенту для проверки и приема работ. Клиента все устроило (вроде как на тестовой базе несколько человек поработало). Договорились что 12.11 переносим в основную базу и начинаем работать. 12 загрузили начали работать. Первый 2 часа все ОК, а потом выяснилось что забыли про один режим работы документа (в ТЗ забыли написать). У заказчика претензий к нам нет, но предприятие встало. Режим мы доработали за 15 минут, еще 1 час ушел на тестирование. А предприятие без этого режима работать не может. Обновили динамически и все встало на свои места. Если бы не было динамического обновления то пришлось бы выгонять 60 пользователей из 5 удаленных точек (2 в других городах) в самый сезон продаж. А если бы я еще бы бекап залил и они бы потеряли 2 часа работы было бы еще веселей. Так что динамический режим очень помогает иной раз.

нормально ДО работает. Если руки кривые нечего на рожу пенять.

(260) Регурярное использование - еще как сказывается. Человек расслабляется и начинает сначала гнать брак, а потом уже и до ГК недалеко. Ну и один раз - не пид..(зачеркнуто) не страшно.

(264) это каким образом человека может расслабить использование встроенного механизма платформы?

(262) хороший пример. но чтобы вы делали, когда потребовалось бы не только менять код, но и метаданные? тогда бы вы в принципе не были бы готовы к решению проблемы подобного рода.

а если бы вы подготовились к внедрению нового блока, то заранее предусмотри все небходимые действия в таком случае. пользователи были бы заранее предупреждены в возможной остановки 1с на несколько минут.
1. сегодня обновляем конфу.
2. пользователям рассылается информация, что в 12-00, в 15-00, 18-00, с предварительным уведомлением за 10 минут возможна остановка работы на 3-5 минут.

(261) Да, именно так. Но с точностьюдо наоборот: "Укажите мне место, куда я не могу доехать на машине, а только пешком добраться" :(

"Обычное" или "демоническое" обновление - это альтернативные варианты. Всегда. И как уже было сказано - человек ленив от природы и выбирает более лёгкий путь. Вот и вся диалема выбора :)

(263) +1
где голосовалка ?

а уже писали чито и обычным обновлением убить базу совсем нетрудно ? ;)
Вот в 8.3 все будет делаться динамически, даже реструктуризация, правда, боюсь при высоконагруженной базе это может выйти боком, но обещают выгон пользователей только на время переименования уже сформированных новых таблиц в рабочие.

ну и еще 1 плюс за ДО - 1С не делает ну очень много каких плюшек для разработчиков, на на ДО всеж сподобилась, имхо неспроста это.

(266) в южном парке в серии про ктулху был национальный американский герой "капитан очевидность"

он всегда прилетал на место событий и всем объяснял КАК НАДО БЫЛО ДЕЛАТЬ чтобы ничего не случилось.

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

(267) ходи пешком, не будь лодырем. Обычное и динамическое обновление не альтернативные варианты.

(263) При прямых руках ДО не надо :)

(266) вели бы себя точно также, а именно пользовались встроенными возможностями платформы.

(270) это на какой вопрос ответ то?

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

(274) забудь.

(266) и (270) +1

Посетила смешная мысль: если нужно изменить метаданные - тоже буду спорить о вариантах? :))

(272) руки как палки?

(272) не зависимо от прямости рук есть еще внешние факторы..
100500 раз выше об этом писали с примерами

(575) ты реально не доганяешь?

ДО это не ЗАМЕНА обычному обновлению
это способ решить проблему здесь и сейчас малой кровью  и малой потерей времени для заказчика.

метаданные демоническим обновлением не изменишь. Можно там что то делать с ролями и еще чем то, но ну его нафиг. ДО использую только при изменении модулей.

(280) согласен. но я настаиваю на том, что лучше правильно организовать работу, когда ДО не понадобится в принципе

(282) ну в твоем мире может быть и да..
в
моем нет.
см (229)

ДО и обговление по вечерам/ночам/утрам - вредно) ГБ и всякие рукой водители и юзвери не замечают, что одноэсник работает и для зачем он нужен

(261) В 15 одноразовая ручная коррекция + плановой обновление, после планового обновления пересчет чтобы проверить, что все корректно.
По расчету себестоимости - зависит от изменений. Если вы правили общие модули, проведение, то вопрос - можно ли было обойтись без. Можно ли было сделать все в рамках 1 обработки хотя бы на период первичной промышленной экслпуатации (когда идет фактически тестирование в рабочем режиме). Делалось ли регрессионное тестирование нового функционала?

(283) просто твой мир пока слишком мал и ограничен :)

(284) ну если тока так )

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

(286)как раз вовсе даже и наоборот :)

(289) все возможно. ведь все зависит от точки зрения :)

(265) Да самым обычным - отсутствием организации труда. Это влечет то, что человек не составляет алгоритмов до начала кодинга, что, в свою очередь, ведет к увеличению глупых ошибок и размножению багов, но поскольку он может запросто их исправить динамически - это его не волнует. Ну и далее по наклонной. А вот когда за каждое ДО по вине программиста у него снимают 20% зарплаты - он начинает работать гораздо качественнее.

ужасы .. секта мазохистов.

(291) мир не состоит тока из кодинга..

(291) фига себе, кодинг реально связан с использованием ДО? В голову такого не приходило.

+(294) а использование молотка при забивании гвоздей вместо камня на что влияет?

(292) Это всё мелочи бытия...

Мня вот более глобальный вопрос беспокоит: "Почему трава - зеленая? Мы ведь глядим на мир в отраженном цвете?"

Как человек может быть объективен, если восприятие мира у него - субъективно?

(293) Ну я же написал "Ну и далее по наклонной".

(294) А ты сравни образцы кода тех, кто может и использует постоянно ДО, и тех, кому каждое ДО надо с начальством согласовывать, и если что - он пострадает материально.

(295) ДО - это как раз камень и есть ;)

Камень, молоток... Микроскопом надо гвозди забивать!

(298) Да вот не дала 1С нам микроскопа :)

Дала! Мы им долбим себе гвозди в крышку гроба. Но не все это понимают.

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

Если быть честным перед самим собой: Использую ли я демоническое обновление? Да, использую! Но этоне значит что я его люблю. Это инструмент и ничего более - как его можно любить или не любить. Надо просто уметь его применять и (главное) понимать когда его можно не применять.

ну вот, опять К.О.

Фуф осилил, внесу свои пять копеек, по поводу ДО, оно действительно в некотором виде расслабляет кодера, ибо он не напрягается по поводу заработает/незаработает, обновиться 100500 раз динамно и все ок, т.е некой дисциплины не хватает. Но всетаки с ДО намного проще жить, типа сделал дело и гуляй смело, и не жди вечера/ночи и тд.

своё имхо я высказал еще в далеком... ммм... забыл в каком году... пойду поищу ветку.

ДО придумано не для расслабления кодера, а, прежде всего, для внесения срочных изменений в базу при условии, что ее стопорнуть нельзя. Реально этим пользуются чаще.

Для чего придумано понятно, а как оно реально срабатывает видно.

(301) Если ты квалифицированный специалист - ДО тебе просто в 99,9% случаев не понадобится, потому что ты сразу напишешь как надо и без ошибок. Ну а если ошибка, все же, просочится - то у тебя будет несколько вариантов как ее обойти без аврального обновления конфигурации. Ты же специалист! Я не зря написал "может и ИСПОЛЬЗУЕТ ПОСТОЯННО".

(305) Если у тебя постоянно срочные внесения изменений - то в консерватории что-то не так.

Все не читал.Помню последнее крупное внедрение в логистической компании в которой режим работы ИТ системы 23*7. Могу сказать что в подобных случаях без динамического обновления никуда. Перед обновлением делали копию таблицы конфиг, в случае сбоя быстро востанавливали. Как правило ничего страшного. Сбой происходил наверное каждый 20-ый раз.

(304) + вооот, нашел всё таки - v8: Коллеги: выскажу своё мнение про демоническое обновление конфигурации

(307) При массовой разработке ты как специалист не сможешь обеспечить такой процент ошибок. Представь 20-ть программистов , у каждого свои объекты, свои глобальные процедуры и функции, куча интерфейсов. Ошибки будут возникать на стыке. К тому же если система пишется с нуля. На определенной фазе ты даже объект не сможешь протестировать полноценно.К примеру если он использует какую нибудь огроменную функцию глобального модуля а она еще не написана. Да можно поставить временные заглушки, но это не будет полноценным тестированием.

ну то был далекий 2008 год, все было полусырое

(307) у меня как раз все в порядке. Консерватория (и не одна)  живет и здравствует. Хотя, иногда мне кажется, что любой бизнес по своей сути - обычный бордель, за деньги клиента исполним любое желание. Главное, чтобы клиент был доволен.

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

(310) У 20 программистов будет организатор проекта с парой-тройкой помощников, в задачу которых и будет входить предотвращение таких ситуаций путем составления грамотных ТЗ и правильного разделения работ по программистам.

(313)+ Ну и конечно 24/7 никто не отменял. Собственно даже 16/7 по сути обязывает программиста вносить структурные изменения из дому поздно вечером.

Ничего не изменилось :( Вы говорите что мир движется, а я говорю - он стоит. Попробуйте оспорить.

Тут хоть кто-то есть, кто реально знает как именно происходит демоническое обновление? Если нет - тогда об чём мы спорим?
Демон - он и есть демон. Мир - стоит!

(314) Через меня уже не один такой "руководитель" прошел. Только как крупный проект - сразу спесь всю как рукой снимает. Прим массовой разработке и сжатых сроках ваши заявления просто утопия.

(314) грамотно составленное ТЗ манагерам? ЛОЛ.

(314) расскажи это НАСА, например, у которых корабль упал в результате программной ошибки. 100% гарантию может дать только росгосстрах.

... манагером?

(313) 1. Он же специалист! Посмотрит, для чего пишет - и сделает работу без ошибок.
2. В таком случае у них специалист работать просто не будет, что и требовалось доказать. Правда, после определенного предела он попадет на то, что внесение малейшего изменения этим неспециалистом приводит к очень неприятным косякам в других местах.

(315) О боги! Пакетный режим на что? Пишешь 1 раз скрипт - и ставишь его исполнение по расписанию.

(317) Читай (6). Крупный проект в сжатые сроки - это неправильная организация и есть.

(318) Каким манагером? И руководитель проекта, и его помощники - это специалисты-программисты, которые переросли уровень обычного программиста и стали гуру. Они теперь не кодят вообще, они теперь пишут алгоритмы и детально прорабатывают взаимодействие различных частей этих алгоритмов. И на этой основе составляют ТЗ.

(319) И чем бы им ДО помогло? Плюс если бы ПО для этого корябля писали 1Сники, привыкшие к ДО - корабль развалился бы уже на нулевой секунде полета. Так что не надо тут сравнивать, задачи по сложности различаются на порядки.

(322) >>Крупный проект в сжатые сроки - это неправильная организация
Это могут быть запросы заказчика.

(322) Руководитель проекта пишет алгоритмы?????? Пятница началась не иначе.

(322) "..Крупный проект в сжатые сроки - это неправильная организация и есть.."

Ну конечно, для людей делающих печатную форму в течении года, другого динамическое обновление не особо нужно.

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

(323) Но организация труда от этого правильной не становится. Да и, как правило, если заказчику надо здесь и сейчас, да еще и качественно - то он жмот, и надо 100 раз подумать, прежде чем с таким связываться.

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

(325) Для печатной формы динамическое обновление не нужно в принципе.

(327)
>>если заказчику надо здесь и сейчас, да еще и качественно - то он жмот, и надо 100 раз подумать
Не факт, что жмот. А думать всегда надо, кто ж спорит :)

(327) В большинстве случаев заказчик за сжатые сроки и их строгое соблюдение готов крупно доплачивать.

(191) хах, 10041697 - с моей подачи. Нашел в почте
//...
     Ответ отдела разработки программ:

  Ошибка зарегистрирована (Код: 10041697).
...//

Правда, описание кривоватое, проблема возникает только при конфликтах блокировок, иначе все работает корректно. Разумеется, в нагруженных базах конфликты часты и баг "актуален"

Сейчас это уже исправили вроде.

(329) Имхо, главное, чтобы при этом он также был готов нести риски.

Нуф-Нуфа хватило на 2.5 часа...?

(328) Ну когда назовешь сумму за "в сжатые сроки и качественно" - вот тогда и поймешь, что большинство жмоты :)

(329) Не настолько крупно, чтобы исполнитель брался гарантировать и сжатые сроки, и качество. Либо сроки не такие уж и сжатые. Если, конечно, под качеством понимать возможность управляемого расширения программы в дальнейшем, а не только что программа работает здесь и сейчас.

P.S. Я про договоры типа "Успеете за месяц - получите 5x цену, успеете за 2 - ничего не получите, не успеете за 2 - заплатите нам n-е количество денег в качестве компенсации ущерба".

Хотя.
"Быстро, качественно, дешево. Выберите любые два" - классика.

(327) а описание проекта - алгоритм. Предупреждать надо, что проектами не занимался ни разу.

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

(335) Для программиста - алгоритм ;) А поскольку по-правильному руководитель должен быть бывшим программистом - то и для него это будет алгоритмом реализации проекта.

Ну а если руководитель - "эффективный" менеджер, то понятно, что кроме малополезных писулек от него ожидать нечего. Хорошо если он просто сможет разруливать пущенный на самотек проект.

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

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

(338) А может, если взглянуть по другому, то только из программистов (ну или, так скажем, из занимавшимися предметной областью "в полях") и вырастают хорошие, грамотные руководители? Один из сотни, это да, но только из этой сотни, а не из левой области.

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

судя по этой ветке, многим прогам до руководителя очень далеко. а отдельные так вообще не дойдут

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

С чего ты взял что было подругому? Руководство компании в пятницу всех оповестило. Я лишь описал что все мы люди и все ошибаются. Очень хорошо, что 1с дало возможность обновляться динамически.

(341) Способности руководителя, они конечно развиваются, но по большей части врожденные. А области разные бывают, в 1С то ясно, любая домохозяйка может :)

(255) К клюшкам есть turbomd, жалкой пародией на которую и является ДО.

(291) Смишно. Ох как смишно.
То, что в нормальных средах программирования присутствует, как обязательный, само собой разумеющийся элемент (динамическое обновление) 1сниками воспринимается, как злое, неведомое и неподвластное науке шайтанство.
Я лично использую динамические обновления уже два года, регулярно - полет нормальный.
Да, дуркует ска с кэшем, но и что из того? У меня после обычных, кошерных и ортодоксальных обновлений из шаблона такие глюки вылазили, что любо-дорого.
Бэкапы спасут отца русской демократии.
(252) 200 гигов? Охренеть. А зачем так много? Обрезать базу - не, неслышал? Боюсь спросить, а ЧТО там вообще?
Кстати, такие размеры БД - задачка не для 1с. Даже не для MSSQL. Из практики - полноценно умеет такие базы только оракл.
По части базы в 80 гигов и железа - знаете, а есть такая штука, как холдинг. Удивительно, правда? )))) Так вот, на этом сервере крутится не одна база в 80 гигов, а два десятка. И железо там весьма и весьма. Кстати, и серверов не один, а три - терминалов, скуль и сервер 1с. И ничо, потратились, т. к. холдинг однако.

(342) Некоторые проги, судя по этой ветке, и в простые обновленцы не годятся.

Кстати, Скуль умеет обновляться "на лету" и при изменениях структуры таблиц. И никого это не шокирует.
До чего дошел прогресс... (с)

(327) Хорошо. Ну, построил ты заказчика. Убедил оптимизировать бизнес-процессы. Все прекрасно и замечательно. Сферический конь в вакууме.
Но вот беда. Есть еще, сука, ключевые клиенты, покупатели или поставщики, которых ни ты, ни заказчик построить не можешь. Их надо удовлетворять. Просто удовлетворять. Всеми возможными способами, иначе, прибыль - до свидания.
Плюс всякие фискальные органы со своими дурками, и все.
Капец коню в вакууме, да здравствует динамическое обновление!

(347) 1. Все просто - после ДО регулярно вылезают глюки, и иногда база вообще разваливается или сервер всех выбрасывает. А после обычного обновления я уже и не припомню когда вылезло что-то хотя бы напоминающее глюк. И это несмотря на то, что ДО делается в десятки раз реже обычного.
2. Разве это много? Всего-то 3 года учета, причем обрезать их никак нельзя, ибо есть договора, не закрывающиеся годами, и надо детальную информацию по ним иметь всегда под рукой. Есть налоговая, которая может копнуть и глубже 3 лет. Копаться в 1 базе как-то удобнее, чем в 3-4.

(349) А скулю-то что? Надо чтобы его клиенты правильно сориентировались в изменившейся структуре таблиц.

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

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

(351)1. Регулярно - художественное преувеличение. Я на такое не натыкалась, хотя использую ДО регулярно.
А вот с обычными обновлениями нарывалась раза три-четыре.
2. 200 гигов это не много. Это - дохуа. Я понимаю, что удобнее печатать отчеты зараз, но вся отчетность сдается либо по году, либо по кварталу. И ее с минимальными затратами времени можно распечатать из трех баз.
Объективно только зарплата требует наличия в базе данных за два последних года. В силу нормативного обоснования расчетов.
Все.
3. Если пользователю надо изменений - он перезайдет. А остальные не заметят. Что и требовалось.
4. Я припомню, когда ключевой клиент приезжал в офис и тряс перед носом главбуха документами и требовал, чтобы перепечатали весь квартал. Да, вот прям сейчас. А то ему в командировку завтра и три недели ни подписей, ни печатей не будет. А если не сделаете - отключим газ.

(353) 1. Да ладно, те же глюки с кешем хоть у кого-нибудь, да вылезают. Иногда часть пользователей просто выбрасывает, причем если с обычным предупреждением они, хотя бы, знают, что такое возможно, то после ДО для них это полная неожиданность. Ну и прочие разные аномалии, случающиеся аккурат после ДО.
2. Руководство тоже требует отчетность не за 1 год. И хочет само нажимать кнопочку - и чтобы ему все вылетало.
3. Т.е. SQL следит за версией клиента и в зависимости от его версии выдает ему нужную структуру таблиц? Для необновившихся клиентов старую версию, для обновившехся - новую, а для тех, кто уже месяц не обновлялся - вообще старую-старую версию?
4. Делается внешняя обработка, которая автоматизированно печатает весь квартал по нужной ему форме. Ничего обновлять не надо. Это даже если в конфигурации нет подключаемых печатных форм.

(354) 1. У меня они почему-то вылезают не после ДО, а после обычных обновлений. Бывает, чо. Но при чем здесь конкретно ДО?
2. Руководству нужна отчетность. Из скольки баз ее соберут - по большому счету пофигу.
А вот программист должен понимать, что держать базу 200 гигов под МсСкуль - не есть гут.
Про волшебную кнопочку не надо рассказывать, руководство было бы не против, чтобы кнопку нажал, и из сидирома купюры вылезали. Но, увы, нет технической возможности.
3. Забыла ключевое слово при "некоторых" изменениях структуры. Есть такие изменения (например, удаление целой таблицы), которые динамично сделать просто в принципе невозможно. Но там, где возможно - почему нет?
4. А потом? Каждый квартал прибег ключевого и перепечатка из внешних печформ? Я лучше сразу изменения внесу, чтоб и потом ему счастье было. Аутоматично.

(353) Ага. Приходит ключевой клиент и просит предоставить ему отчетность с 01 августа 2008 года по текущий момент (реальный пример) Ибо он проходит аудит. Причем информация нужна срочно сводная (за весь период) и детальная (по каждой позиции). И печатай ему из скольки баз, если прирост 100 гигов в год? И потом своди 50 тысяч строк в Excel-е...

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

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

IamAlexy +1
Нуф-нуф - сноб
На крупных внедрениях 7.7 24/7 у меня внутри МД был только скелет метаданных, все остальное - внешними обработками и файлами модулей с турбомд.
В восьмерке заявлена штатная возможность - это отлично,  можно, например, не останавливать круглосуточную работу экспедиции если обновился модуль расчета налогов по зарплате.

(355) 1. Возможно, эти проблемы и есть следствие ДО ;) Потому что у нас проблем с обычным обновлением совсем немного. Даже 5 штук не наберется за все время во всех базах.
2. Оно уже сейчас получает это 1 кнопочкой, а тут ИТ-отдел приходит и предлагает им добровольно отказаться от этого. Потому что у них там что-то не получается, ага.
3. Да без разницы, когда меняется структура, необходимо синхронизировать СУДБ и клиентов, иначе получается слишком сложно реализовать это без глюков. А 1С даже с простым ДО без изменения структуры пока справиться не может.
4. А потом ты вносишь в плановое время изменения в конфигурацию обычным обновлением, если это не разовое требование, и удаляешь с диска эту обработку нафиг.

(354) +1 регулярно ловили глюки кэша на динамическом обновлении. При чем, глюки мерзкие и внезапные. А вот при обычном обновлении ни разу не было подобного (тьфу-тьфу).

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

(356) Больше 65 536 строк в эксель вы все равно не запихаете, хоть  обпихайтесь.
Чем не устроит клиента три отчета по одному году каждый?
(357) Вот именно. Сильно зависит от архитектуры конкреной базы. Кто, кроме 1с видал решения, тот понимает, что у 1с все не так хорошо нормализовано, чтоб прям 200 гигов тащить и не пукнуть ни разу.

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

(358) Всеми силами приветствую эту штатную возможность. До ума пусть доведут и  отлично будет.

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

(361) Это некоторое преувеличение. Есть обходные пути, в том числе доступные обычным пользователям - например вывести как mxl, и руками порвать на несколько xls файлов. Это не говоря про программные варианты.
А так все просто - аудиты и фискалы. Есть требование. И ты должен его выполнить. И даже если потребуют напечатать и отдать им в бумажном виде, то надо напечатать и отправить им газельку бумаги (благотакой маразм достаточно редко происходит).

(362) Насколько я понмю - были проведены официально зарегистрированные баги, когда после динмаческого обновления именно из-за него

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

(Sammo,  ptitsa-radio)
не понятно, что вы мусолите про отчеты, у вас что нет возможности развернуть копию продакшн базы?

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

(367) Да есть все возможности, я только не понимаю, нахуа держать базу 200 гигов за три года, когда можно сделать три базы по 60 гигов за каждый год. Ни одно животное при этом не пострадает.

(365) насчет "газельки бумаги" вы не правы - такой маразм имеет место быть постоянно. На алкоголе, например.
Но даже РАР не требует сводных данных за несколько лет в совокупности. Из трех баз печатается газель бумаги так же прекрасно и быстро, как из одой. Даже быстрее.

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

(371) В Петропавловске-Камчатском полночь. Точне, уже час ночи )))

(369) ерунда, не забывайте, вы базу ведете не только для фискальной отчетности.

(373) Для управленцев тоже важен год, как единица. Режу базы клиентам каждый год, радуются и пляшут. И никто еще не попросил сложить три цыферки за год каждый. Как-то сами управляются с этим.

(368) Еще раз реальный пример.
(367) Да, пожалуй отклонились от темы.
Имхо, если доделают механищм, то можно рассмотреть динамическое обновление. Кстати, сейчас оно более безопасно, чем пару лет назад.
Но, имхо, сейчас динамическое обновление - это "стоя и в гамаке"

(375) Да, ограничено, с предохранением и по большой нужде. Но тем не менее,использование ДО не есть "быдлокодерство". Бывает, что и объективно необходимо. А если доведут до ума, так и вообще - прекрасная штатная возможность, изнит?

Ну не знаю...
Все проблемы динамических обновлений решаются чисткой кэша.
Не понимаю этого кипежа...

(377) Вопрос почему они вообще возникают? Разве 1С не может сравнить гуид кэша и текущей конфигурации?

(378) бинго! пришел капитан Очевидность! :)

(379) Почему это возникает на протяжении стольки лет?

(377) не только. на 8.2.15 появилась ошибка при которой восстановить работу базу можно только путем ручного восстановления таблицы config, либо откатом на 8.2.14. исправили или нет - фиг знает.

(374) плановики любят, когда у них в базе несколько лет. сравнивают там чего-то, интерполируют :)

Сколько де тут быдлокодеров...

(383) примерно столько же сколько теоретиков которые практически ни с чем не сталкивались в жизни своей однако в теории все знают но  всех поучают..

(384) В жизни(например на работе), гораздо реже. На форуме и по пьяни - О,да! это они мастера:)

(384) продолжай себя успокаивать :)

Дак чё, платформа глючная в итоге или нет ? )))

(387) местами и в отдельные отрезки времени, вообщем как обычно)

А ни у кого такой проблемы не было на 16 релизе: делаешь "Загрузить измененную конфигурацию", а после загрузки (очистка кэша, закрыть открыть конфигуратор) она отличается от загруженной?

На прошлой работе над базой работало 7-8 человек (разработчики+поддержка), в базе онлайн под 800 пользователей, динамические обновления были чуть ли не каждый день, ибо "неработа" пользователей (продажники) в течении 15 минут приводила к миллионным убыткам для холдинга. "Большие" обновления в выходные поздно вечером по регламенту. А Нуф-Нуф все про ларьки свои вещает.

Народ, никто не замечал, что 8.2.16.368 подвисает иногда при обновлении?! Вернее после обновления, когда из конфигуратора захожу в Предприятие процесс виснет.
Особенно часто такое встречаю, когда база файловая лежит на другом компе в сети, а обновлять приходится с удаленного.

(390) а что было в этих обновления, если не секрет?
Что может потребовать ежедневное обновление кода, кроме как говвнокод?

(392) даже тебя мама с папой родили не сразу такого из себя умного
пришлось допиливать тебя в школах и прочих институтах, правда же?

никто же не говорит что ты сделан сам понимаешь из чего..

а вообще есть мнение что если стремиться выпустить сразу идеальный продукт  то продукт с очень большой долей вероятности выпущен никогда не будет..

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

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

(374) 200 Гб это небольшая база. У нас в продакшене 1.5 Тб, на 1С и ничего. работает. И даже хорошо. И ты не поверишь  - все эти данные нужны.

(5) > Любители обновляться динамически имхо по большей части латентные гомосексуалисты.

Да вы, батенька, знаете в чем толк!

(291) Дык просто нужно как в старые добрые древние времена программерам выделять машинное (платное!) время и всё - дисциплина на уровне, попробуй ошибиться, очередь на "всунуть свою перфокарту" просто съест. А вообще - чепуха, дисциплина программирования, думаю, напрямую связана с качествами и воспитанием самого программиста, а не с предоставляемыми ему возможностями инструмента. ДО - однозначный респект 1С!

(392) А тебе не кажется, что быдлокодерами являются как раз создатели 1С. С этим обновлением куча проблем и решить они её не могут и при этом отключить эту фичу у них мужества не хвытает? Почему рерганизация БД может происходить без отключения, а изменение в конфигурации нет? Может что то в консерватории?

пятница хороша была, даже никто не запостил
http://www.1c.ru/news/info.jsp?id=15898

Новое в версии 8.2.17 платформы "1С:Предприятие"

   Реализована поддержка:
       операционной системы Microsoft Windows 8,
       системы управления базами данных Microsoft SQL 2012,
       веб-браузера Mozilla Firefox 15 (Windows, Linux).
   Упрощена процедура получения программных лицензий.
   Исправлены выявленные ошибки.

(398) Покорми оленей v8: v8: 8.2.17 финальный релиз

(400) бАлин

все-таки интересно, что же там у Phace такого было...

(401) интересно+1, но аргументом быть не может, т.к. архитектура решения должна учитывать специфику бизнеса, иначе это звучит так: мы создали решение, которое очень тяжело поддерживать. Приведу пример из личного опыта: бизнес 24/7, 1С 7.7, УРБД. Для выполнения обновлений, связанных, к примеру, с пересчетом итогов, в точках продаж были резервные узлы, которые обновлялись, и пользователи перебрасывались на них.

Такую веселую ветку проморгал ))

Апну срач

(404) во ты свин )

v8: НЕ динамическое обновление и локальный кеш

(392),(401),(402) Да, в большинстве случаев это исправление косяков товарищей участвовавших во внедрении, всплывающих в определенные моменты эксплуатации базы. Но только не надо продолжать обзывать всех тупыми и только себя признавать умным и пишущим идеальный функционал без ошибок. Внедрение курировал Сергей Нуралиев.

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

(407) значит плохо курировал, раз столько гамнокода была :)

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

(409) Ну обычно серьезные продукты требуют серьезного подхода к разработке и тестированию, при котором необходимость динамического обновления сводится к минимуму. Конечно остаются моменты, когда оно необходимо, когда несколько этапов тестирования пропустило гамнокод, когда нет другого выхода - никто не запрещает динамически обновить (зная о возможных багах динамического обновления в 1С). Но в данном случае - динамическое обновление используется как раз при причине гамнокода. Точнее для исправления его последствий.

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

Нуф-Нуф против говвнокода!

(411) Угу вот так понадеешься, а потом лечить копией
v8: 1C 8.2 (12.78) Нарушена целостность структуры конфигурации
Причем инструментов восстановления у 1С нет. Вручную ребята. Так кто там ковнокодер?
Не умеете программировать, убирайте фичу. И ты и я будем довольны.

Существуют ли некие правила безопасного использования ДО?
Было бы интересно увидеть опыт в сжатом виде, к чему плохому оно приводит. А тут лирики на 5 страниц :)
P.S.
я так для себя понял , что нужен бекап буквально перед каждым обновлением , даже если поменяна одна буква.
и ДО использовать только тогда, когда отвертеться невозможно.

(414) база на полтеррабайта тебе в помощь, набэкапишься вдоволь

я динамическое обновление не применяю

научитесь наконец кодить нормально. и динамическое не понадобится

(417) Ваша позиция понятна. Вы её уже повторили раз 10.

(418) Я согласен с Нуф-Нуф. Научитесь кодить нормально, научите программистов, работавших на этом месте до вас, кодить нормально, научите заказчиков с сотней работающих юзеров не хотеть странного "вот прям щас", причем из базы юзверей выгонять нельзя. Научитесь всему этому и ДО не понадобится. :)

(419) Кодить нормально - можем, программистов учить кодить нормально - можем, заказчиков с сотней работающих юзеров не хотеть странного - не можем. И НИКТО НЕ МОЖЕТ.

(420) В (419) был сарказм.

а официальная позиция 1С на эту тему как звучит ? в каком фолианте её смотреть на ? :)

Проблема в масштабах. Когда для вас проблема выгнать 20 человек из базы, то действительно - пользуйтесь динамическим обновлением. Даже если крашнется - откатитесь, мелочь, комфортом удобнее, я сам так предпочитал делать в франче. У нас сейчас несколько больше сотни людей работает в различных филиалах постоянно онлайн, в разных городах, работа идет круглые сутки (3 смены людей). И все выходят, в строго установленное время (утром) для обновления, кто не выходит (тех выкидываем). Ибо 1 раз при ДО поехала конфа (работала не та, что применилась, а та что закешировалась). И день филиал проработал по непонятным правилам. Риск такого события в материальном плане существенно опаснее при таких масштабах, чем несколько минут простоя.

(423) +1

Хера демагогия развернулась. Автор решил проблему-то?
У меня была подобная херня - из бэкапа в sql скопировать таблицу config надо..
Если не поможет, то надо синхронизировать структуры.. (могу подробнее описать при надобности)

А, смотрю помогли.

(421) Я не против. Но все-таки, нормально кодить - можно. Отучить заказчика хотеть странного - никогда. В современных условиях.

ДО появилась нефига не ради исправления Gовнокода.

(425) Да, впервые с этим столкнулся... за то много поучительного узнал. Случаи как у (423) тоже были, не мог понять в чем дело.

Нуф-Нуф видимо просто не работал на предприятиях которые работают 24х7, c сотней пользователей в базе.

Dmitri888 видимо просто не работал на предприятиях с нормально поставленными и регламентированными процессами ИТ с тысячей пользователей в базе.

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

(431) Нуф-Нуф
что то я вам не доверяю)) про Вашу тысячу онлайн пользователей в одной базе))


(432)  Dmitri888
а Вас поддерживаю))
да бывают Глюки с дин.обновлениями - но решить их за 5-10 минут вполне реально))

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

1)создаем пустую 1c базу на том-же sql где основа
2)Основу и "пустышку" подключаем к Хранилищу конфы
3) в случае сбоя "пустышку" -обновляем из хранилища

4)
Use БД_РАБОЧАЯ
go

Delete From [DBO].[Config]
go

insert into [БД_РАБОЧАЯ].[Dbo].[Config] select * from [Пустышка].[Dbo].[Config]
go
5) и желательно почистить кеш самого "сервера 1С"

ps:
естественно всех прийдется выгнать из на 5 минут

из 1с

(434) даже если ты сранный фокусник и сможешь провернуть это за 5 минут - то на какую сумму уменьшится твоя ЗП и на сколько расширится твое очко в качестве кары за 5 минутной простой организации 24/7

все не читал, так че там? при дин. обновлении кэш портится да?

(432) у тебя все базы запускаются с флагом /клеаркэш?

(438) карма портится

(440) в 8.3 все ок будет?

(440) зачем тогда 1С сделал это штатным механизмом, есть версии?...

вообще забавная ситуация с ДО. помню во времена главенства 7.7 все сопели про убогую 1С, которая не умеет штатно обновляться динамически, если не было изменения структуры данных. теперь, когда 1С такой механизм сделала, выясняется, что это портит карму...

(443) А зачем нужно это динамо-обновление, если потом целостность структуры разрушится? Два раза попадал, что-то больше не хочется.

я вот не пойму если механизьм ДО косячный то это не значит что ДО это зло

по мне так не важно ДО или просто обновление, если есть ДО почему бы не воспользоваться?, а вот то что с кешем трабла так это известная криворукость

(443) 77 умеет почти :-) штатно обновиться, если не было изменния структуры...

(444) это уже вопрос к реализации механизма, а не его необходимости...

(446) с помощью турбобл?...

(448) С помощью unlocker'а :-))

+(448) или текстовых модулей объектов?...

(441) Да. Там не будет ДО :-)

(446)если по вашим словам ДО это латентный гомосексизм то как назвать то что вы предложили???

(452) Это называется "оперативное внесение незначительных изменений".
Кстати, про латентность я не говорил.

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

(453)сорри ошибся это слова Нуф-Нуф 'а

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

(454) анлокер - это поделка неизвестного автора? :-)

чуть офф: 8.2.17.143 - по ущещниям норм? после НГ переходим с 15.319

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

(459) И турбо умеет. И загрузитьизфайла умеет. Но это требует изменения конфигурации :-)

(459) На, ознакомься. wiki:Unlocker

Если нет бэкапа, то разве обычное обновление не менее опасно, чем динамическое?

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

(461) да уже не пригодится. в этом году последнюю семерошную базу на 8-ку перевел ;)...

(463) да в любом случае пригодится... Нет для 1с, так для чего другого...

Кто-нибудь здесь на 5 страницах уже рассказал как пользоваться динамическим обновлением с умом? А то интересно...

Нуф-Нуф (437)
раз уж пошла такая пьянка с переходом на личности
>если ты сранный фокусник ....

вот сколько видел на мисте ваших сообщений
вы НИЧЕГО кроме как ОБО...РАТЬ кого не пишите дельного...
крупный ТРОЛЬ однако не иначе ))

1)ДО - слетает не так и часто (у меня примерно раз месяц)
2)без ДО - писать что-то с месяцок с отрывам от реальности...
и возможно не то и не так ... может только самоуверенный долб...б.

(465)  blutang

ДО - это рулетка))
как быстро лечить если ВЫСТРЕЛ)) ...   (434) sanfoto

(467) не, это уже если выстрелило. А вот, чтоб не стреляло - как надо ползовать ДО с умом? Слыхал, что надо выгрузку/загрузку базы сделать как можно быстрее, если пришлось воспользоваться ДО.

А вот ещё интересно: ДО стреляет только по новым объектам и реквизитам, а код, дописанный в старые объекты, не трогает?

(469) ДО - при добавлении Новых реквизитов и Объектов НЕВОЗМОЖНО!

А забыл добавить...

меньше всего вероятность слета конфы при ДО - когда конфигуратор запущен там-же где и "сервер 1с"

+ еще уменьшает вероятность слета при ДО
1)использование 64 бит - сервер 1с
2)на сервере должно быть достаточно Оперативки...
ну как минимум чисто под "сервер 1С" около 4 Гб... уход в файл подкачки повышает вероятность слета.

>>Слыхал, что надо выгрузку/загрузку базы сделать как можно быстрее, если пришлось воспользоваться ДО.

Кэш надо иногда чистить у пользователей после ДО, выгрузка/загрузка пока не требовалась

(470) я тоже раньше так думал, но у меня получилось и объекты добавить в ДО, и заполнить их данными. А при следующем обновлении конфигурации всё и пропало.

(474), как?!

Как пропало? Пропали объекты со всеми данными :) А код, добавленный к старым объектам, остался. Был расстроен, но из бэкапа и с помощью КД всё восстановил.

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

В 8.3 обещают динамическую реструктуризацию

(476) небось обновление конфигурации базы делал не тормознув регламенты.

(479) 4 года конфигурацию обновляю - ни разу регламенты не тормозил

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

(468) >Слыхал, что надо выгрузку/загрузку базы сделать как можно быстрее, если пришлось воспользоваться ДО.

Кто-то рекомендовал процесс новый запускать на сервере предприятия перед ДО.

не читал, но осуждаю

(480) тогда ничего удивительного.

из последнего

У нас в конфигурации делались изменения на месте у клиента с динамическим обновлением. После чего сделан архив (dt). И проблема воспроизводится с этим архивом на новой базе (никакого кэша), и без распределенки в файловом режиме. Проблема выглядит так:
В пустую базу восстанавливаем архив. Затем сохраняем конфигурацию в файл. Делаем сравнение конфигурации с файлом - все идентично.
Делаем "Загрузить конфигурацию из файла" - выбираем тот же самый файл - происходит загрузка кинфигурации (не делаем обновление конфигурации БД). Смотрим - наши изменения все на месте. Затем нажимаем на "Обновить конфигурацию базы данных" - и те изменения, которые мы делали и применяли динамически В ДРУГОЙ БАЗЕ - исчезают!
При этом делаем сравнение с файлом - различий нет!
После всего этого если зайти снова и произвести какие-то изменения (в нашем случае были изменения в управляемой форме) - поставить пробел в модуле, например - то при сравнении все с тем же файлом конфигурации появляются различия по всем нашим изменениям, которые исчезли после обновления конфигурации базы данных!
Платформа 8.2.15.319.

http://partners.v8.1c.ru/forum/thread.jsp?id=983313

(485) интересно однако. Надо будет взять себе на заметку.