Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Перестало работать демоническое обновление 8.3.18

Перестало работать демоническое обновление 8.3.18
Я
   John83
 
04.02.21 - 14:07
Обновили платформу на 8.3.18.1289
Меняю модуль документа, но при обновлении требует завершить все сеансы.
Причем нажимаю отмену и окно появляется еще раз (не знаю, на сколько это важно).
Какие новшества от 1С?
   John83
 
1 - 04.02.21 - 14:12
кэш чистил
   Dmitry1c
 
2 - 04.02.21 - 14:12
>8.3.18

котик детектед
   ДенисЧ
 
3 - 04.02.21 - 14:16
Нет, это бывало и раньше.
   ДенисЧ
 
4 - 04.02.21 - 14:17
А вообще - нефиг демонически обновляться.
   Вафель
 
5 - 04.02.21 - 14:18
видел такое, но до этого модуль был пустой.
может событие какое добавили?
   Hmster
 
6 - 04.02.21 - 14:19
у меня на 15-ой такое было давно. Забил.
   timurhv
 
7 - 04.02.21 - 14:27
(0) В 8.3.17 нажимаю "Отмена" - "Отмена" - "Обновить динамически" :)
   Kassern
 
8 - 04.02.21 - 15:14
кто то еще демонически обновляется?
   Classic
 
9 - 04.02.21 - 15:15
(8)
Святое дело
   Kassern
 
10 - 04.02.21 - 15:16
(9) надо иметь стальные яйца, чтобы таким заниматься)
   Kassern
 
11 - 04.02.21 - 15:22
(9) Когда то и я грешил с динамическим обновлением, но после того, как база пошла по одному месту после обновления и 80 человек не могли толком работать, немного поменял взгяды на эту "фичу". 4 часа ушло чтобы восстановить базу (утреннюю копию) и вернуть заведенные данные и это еще легко отделался. После этого, данная опция стала табу для меня.
   mikecool
 
12 - 04.02.21 - 15:24
(11) т.е. поправить таблички в скуле не догадался? делов то 10 минут поиска в инете и 5 минут запросы скопировать-вставить - выполнить
   mikecool
 
13 - 04.02.21 - 15:24
+12 единственно - надо накатить потом те изменения, которые были удалены
   ДядяМитяй
 
14 - 04.02.21 - 15:30
1208 - самописка обновляется динамически как и раньше. Пользователей до 20. Ссыкотно только если меняешь доки в которых наверняка кто-то сейчас ковыряется. Тогда общий аларм.
   Kassern
 
15 - 04.02.21 - 15:40
(12) во-первых, это было начало карьеры, если так можно назвать, во-вторых, там был постгрис с которым я не очень дружил и не я его администрировал. Базу развернули быстро, а вот восстановление данных заняло какое то время. Копии были только утренние, транзакции по изменениям не велись. После динамического обновления, как то странно себя база повела, у части сотрудников пропал регистр сведений, а у кого-то все нормально работало и еще заметили косяки не сразу. В итоге с пользователя, у которого все нормально работало в xml экспортировали документы за день, развернули утреннюю копию и восстановили данные. Смысл всех этих танцев с бубнами, когда можно было всех выкинуть на минутку в обед и нормально обновиться...
   Kassern
 
16 - 04.02.21 - 15:51
(15) Вспомнил, что тогда произошло. Добавил регистр сведений, обновился по нормальному, но какого то черта закешился конфигуратор без этого регистра, далее сделал новое обновление динамическое, что то там в логике правил и конфигуратор дал записать такое обновление без регистра. В итоге после входа в базу регистра уже не существовало, но те кто из 1ски не выходил после динамического обновления данный регистр имели. Вот такая бяка может случиться...
   Ёпрст
 
17 - 04.02.21 - 16:04
(8) я.. но у нас есть триггер, на всякий. За несколько лет ни разу не воспользовался подменой.
   AliceLight
 
18 - 04.02.21 - 16:11
(0) главное на боевые динамически не обновлять. А на тестовых я динамическими обновлениями грешу, и такую фигню еще на 8.3.15 встречала
   AliceLight
 
19 - 04.02.21 - 16:14
(11) тоже на прошлой работе ловили глюки с динамическим обновлением на боевой. С тех пор завязали так делать.
Самое простое - в кэше у пользователя старая версия кода останется. Но это мелочи по сравнением с тем, что так можно базу прибить. У нас тоже тогда как в (15) было: у кого-то недоступны какие-то объекты, у кого-то половина подсистем исчезла...
   hhhh
 
20 - 04.02.21 - 16:28
(10) ну Джон он такой.
   Dmitrii
 
21 - 04.02.21 - 17:06
(12) >> поправить таблички в скуле не догадался?

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

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

Мы в один прекрасный момент ввели простое требование.
Если пользователю нужно, чтобы какое-то исправление или доработка оказались в продуктиве прямо посреди рабочего дня, то он должен согласовать с руководством время и продолжительность технического перерыва, когда всех выгонят из базы для его установки.
И свершилось чудо! Если раньше каждая вторая заявка завершалась истерикой пользователя о необходимости немедленно перенести исправление в продуктив, то теперь такое случается крайне редко. Сейчас в 99% случаев почему-то все готовы спокойно ждать до завтра, когда исправление прилетит с ночным обновлением.
   nicxxx
 
22 - 04.02.21 - 19:12
(21) Интересно, когда это не работает SELECT INTO ...
   Ёпрст
 
23 - 04.02.21 - 19:30
(22) когда путают select с delete поди
   timurhv
 
24 - 04.02.21 - 22:42
(16) ну нормально, кэш мне тестовую на 2 релиза назад как-то вернул :)
   dmpl
 
25 - 08.02.21 - 13:56
(19) Косяк может вылезти через год, когда неправильную отчетность сдадут...

(22) А с чего вы взяли, что проблемы всегда одинаковые и не меняются с изменением версии платформы?


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.