Глюк после динамического обновления? #809144

Добрый день. С прошлой недели стал замечать интересную фигню в работе 1С. 8.3.10.2580 Работаю с обработкой или  общей формой . Меняю значение реквизита /  меняю код  добавляю новые процедуры или функции..  Т.е. все как обычно.  Делаю динамическое обновление программы.  У всех пользователей которые зашли после обновления все изменения работают.  Все как надо.  Я не закрываю конфигуратор!!!1 закрываю объект с которым работал . открываю его опять и там все как было до изменения.  Конфикоратор говорит что база не изменялась, но если я запущусь  в режиме отладки то все внесенные изменения ранее пропадают. .  Если перезапустить конфигуратор - все становится на свои места. Изменения появляются. Но после любого изменения и динамического обновления опять откат...  кто сталкивался? как лечится?

динамическое обновление очень глючное

8.3.10.2466 - у меня пару раз было подобное безо всякого динамического обновления. Вылечил ребутом тестового сервера - аптайм был где-то 3 недели, а авторебута не было.

динамическое обновление ЗЛО

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

Смизжено: "Здравствуйте, меня зовут Алексей и я делаю динамическое обновление. Раньше, я делал динамическое обновление по три или даже целых пять раз в день. Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату. Но потом случилось горе и в одно прекрасное обновление база просто не запустилась. Это был ч0рный день в моей жизни. Я потерял друзей, коллеги отвернулись от меня. Жена меня бросила и дети не хотят со мной разговаривать. Попа болела после долгого и многозначительного разговора с начальством. И я решил изменить свою жизнь. Я теперь занимаюсь спортом Стал посещать бассейн. Питаюсь правильно и соблюдаю правила дорожного движения. Сегодня у меня праздник. Я  уже 30 дней не делаю динамического обновления без ахивации базы данных средствами СУБД. Я практически готов полностью отказаться от динамического обновления. Вообще не обновлять динамически. Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов: 12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ 1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении. 2. Согласиться с утверждением, что без посторонней помощи не обойтись. 3. Мысленно перепоручить себя некой Высшей силе, которая поможет. 4. Проанализировать свои поступки. 5. Признать перед собой и кем-то еще свои ошибки. 6. Не сомневаться, что бекап перед динамическим обновлением сработает. 7. Просить высшие силы избавить от недостатков. 8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними. 9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением. 10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили. 11. Не переставать размышлять и благодарить помощника из пункта 3. 12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам. АЛИЛЛУЯ братья и сестры! АМинь!"

распечатал!! 111 =))

Спачибо

начиная с 8.3.10.25хх очень сильно сломали демоническое обновление

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

спасибо за предупреждение! Может настал тот час, когда сами разрабы решат "Хватит это терпеть" и таки починят?

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

А я на 8.3.10.2561 пару раз использовал ДО, и после в конфигураторе что-то делал. Что теперь со мной будет? :))

+ Да, у меня клиент 1С 64х.

>>Что теперь со мной будет? :)) Десять лет расстрела с повешением в газовой камере и каждый день до смерти. )))))

Слухай сюды! Положь колдобину со стороны загогулины и два раза дергани за пимпочку. Опосля чего долбани плюхалкой по кувывалке и, коды чвокнет, отскочь дальшее, прикинься ветошью и не отсвечивай. Потому как она в это время шмяк… ту?дыть, сподыть, ёксель?моксель, ерш твою медь… Ш?ш?ш! И ждешь, пока остынет. Остыло — подымаесся, вздыхаешь… Осторо?о?ожненько вздыхаешь про себя, шобы эта быдла не рванула! И бегишь за угол за поллитрой. Потому как пронесло!

А подробнее можно, чем обусловлено Ваше высказывание? Какие ограничения накладываются на работу в конфигураторе после ДО? Я периодически на базе разработки делаю ДО, никаких глюков не выявлено. (8.3.10.2580). Полагаю, что кэш страдает после ДО, в случае, когда операционка загажена.

Ну вообще, я обычно делаю по методу , но был один-два раза, когда после накатывания cf, выявлялась какая-нибудь незначительная ошибка - запятую забыл в макете поставить или ещё какая опечатка. И для скорости правил прямо в рабочей, применяя ДО. Пока прокатывало, хотя опасения были, конечно.

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

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

очень сильно началось на 8.3.10.25хх и последующих. на 8.3.6.2639 все еще воспроизводится.

Наблюдаю то же самое. Спасает снос папок с кэшем.

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

последние релизы 8.3 более или менее нормально работают с динамическим обновлением, но есть недокументированная особенность - надо чистить кеши. В параметрах запуска 1C:Предприятия (тестовая и рабочая база) указать параметр: /ClearCache При основном обновлении (с отключением пользователей) надо пользоваться бат-файлом: Остановка службы 1С:Предприятие с очисткой временных файлов.

Я вот перезапускаю конфигуратор, когда он просит, и все пучком.

В последних версиях платформы уже не просит :)

+ Параметры запуска находятся в стартовом окне, где кнопки Добавить-Изменить-Удалить. По кнопке "Изменить..." перейти на вторую закладку и ввести (или добавить) значение /ClearCahce в поле "Дополнительные параметры запуска".

Емнип, ключ /ClearCahce работает только для тонкого клиента, а конфигуратор вроде - это всегда толстый. Непонятно, как этот ключ помогает при ДО. Или я ошибаюсь?

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

Я не могу сейчас найти документацию на этот ключ поиском по сайту 1С. Может он всё там чистит, включая и конфигурацию?

10060739  Кеш метаданных Проблема: При частом изменении конфигурации, при использовании тонкого клиента или толстого клиента в управляемом режиме работы, происходит увеличение объема кэша клиент-серверных вызовов. Способ обхода: Выполнить запуск с параметром командной строки /ClearCache. Дата публикации: 2010-08-06

С кешами вообще какая-то ерунда - если они нужны для ускорения обращений без ZIP упаковки и распаковки, то как бы не оказалось, что на современных системах результат получается обратный. Если нужны для полнотекстового поиска по модулям, то может как-то это выделить - базой данных искать. Я не понимаю, зачем они нужны (т.е. какое действие ускоряют). Если секретный ключик /ClearCache их выключает и всё становится хорошо, то возникает вопрос, а зачем они включены.

Скорее всего, ускоряет запись за счет записи без транзакции - а она всегда и повсюду глючит (в любых СУБД).

Вот сейчас у меня сглючило - я посмотрел, а на этой базе ключика-то /ClearCache и нет.

Динамичное обновление самое лучшее:) Нужно только кэши чистить.

Можно файл кэша открыть и посмотреть чего там.

Поддерживаю, сломали что-то.

Мыши и кактусы...

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

при чем тут сравнение?

Вчера еще раз словил эту же проблему - тоже не было /ClearCache.

Лечится отказом от динамического обновления. Ибо программисты 1С бывают двух типов - те кто уже положил базу динамическим обновлением и те кому это еще предстоит.

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

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

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

Словил то же самое при наличии /ClearCache. 1С:Предприятие 8.3 (8.3.10.2639) Видимо, где-то еще есть один кеш - в хранилище, наверное.

8.3.12.1685. ERP. Убрал на форме документа мешавший реквизит. Сделал ДО. У клиентов, подключенных с указанием кластера и имени ИБ, после перезапуска 1С все заработало, а у клиентов подключенных через https после повторного запуска по-прежнему вылезал старый вариант формы. На одном и том же компе, для одного и того же пользователя, для разных вариантов подключения к базе получался разный результат. Чистка локальных кешей и запуск с /ClearCache ничего не дали. Все заработало только после перезапуска Агента сервера 1С (с ожиданием полного закрытия rphost). Т.е. пользователей все равно пришлось разогнать. В чем тогда смысл ДО?