Странное поведение платформы 1С 8.3

Проверьте целостность базы данных, а особенно таблицы config (можно средствами SQL). Как вариант сделать выгрузку/загрузку базы в/из dt.

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

Причина, полагаю, кроется в ошибке 1С, когда после второго динамического обновления генерятся объекты "третьего поколения", т.е. с соответствующими суффиксами, а при обычном обновлении система думает, что они уже не нужны и сносит их, полагая, что в новых метаданных они есть. Криворукие 1С-ные программисты, и ошибки у них однообразные.

Такие глюки бывали не только на 8.3. Танцы на граблях это конечно весело, но больно

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

SQL у вас не какой-то древний? А то в старых версиях были ограничения при которых 1с неадекватно себя вела...

При возникновении ошибки чистить кэш

спасибо всем, кто предлагал свои варианты решения проблемы
но, к сожалению, все варианты - не подходят

1. постоянно чистить кэш - не помогает (уже делаю это на протяжении недели)
2. SQL - 2014
3. каждый раз писать в тестовой базе, а потом переносить всё в продуктив - как-то не очень

P.S. вчера опять пропал кусок кода, который был дописан в уже существующей функции
бред-бредом...

хоть бери и все коды храни в текстовом файле

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

всем ещё раз спасибо за советы - приму к сведению

зашёл на users.v8.1c.ru
8.3.10.2561 11.08.17
8.3.10.2505 21.07.17
8.3.10.2466 05.07.17 - моя платформа

то есть вышло ещё - наверно буду менять платформу
отпишусь, как переусатновлю и всё проверю

P.S. одно из нововведений )))

П-предсказуемость )))

всем ещё раз добрый вечер...

данное сообщение посвящается сторонникам "чистки кэша" - нифига не помогает !!!
принципиально - 2 дня перед каждым динамическим обновление чищу кэш...

причём сегодня было вот что (а был просто полный жесть):
- я добавил в уже существующую функцию общего модуля одно условие;
- сохранил БД;
- обновил БД динамически;
- перезашёл в конфигуратор и открыл эту фунцию - всё ОК;
- отошёл на 2-3 минуты поговорить по телефону (возле ноута никого не было - 100%);
- когда я вернулся обратно - светился "бочонок" обновления конфигурации - якобы я что-то там изменил;
- я нажал - "Сравнить, объеденить с конфигурацией БД" - и что я увидел (!!!) - слева, в основной БД, был мой "свежий "код - а справа, в конфигурации БД - его НЕТ - как-будто я его только-что не написал (см. пример - вложение №1)
- ок... сохраняю конфигурацию - закрываю конфигуратор... ЧИЩУ КЭШ !!!
- захожу в конфигуратор - нажимаю - Обновить конфигурацию - естественно, обновляю динамически.
- принципиально перезахожу в конфигуратор.
- открываю всё тот же общий модуль - мои изменения ОТСУТСТВУЮТ...

а потом было самое интересное - данную операцию я проделывал 2 раза подряд - мой код пропадал..

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

08.11.2017 - ни одного "пропадания" кода не было.
но, опять повторюсь - сама проблема, как по мне, так и не была выявлена - или кэш, или платформа "глючная" - непонятно.

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

Для не нулевого количества админов/программистов считается нормальным ставить ДВА независимых сервера 1с и подключать их к базе. Например на рабочем серваке и на рабочем компе.
Симптомы ну очень похожи...
Если за разработку без хранилища или прямо на рабочей базе просто сразу же увольняют, то за два сервера нужно как в старину ещё и руки ампутировать.

> 3. каждый раз писать в тестовой базе, а потом переносить всё в продуктив - как-то не очень
> количество одновременно рабочих юзеров в БД - зашкаливает
> один час простоя предприятия - около 10000 уе (в среднем)

Да-да, юнит-тестирование придумали трусы))

Тоже было пару раз на хранилище не сохранились изменения причем вчера были даже протестированы на сегодня уже нет кода даже не успел в рабочую поместить платформа 8.3.9 на 8.3.7 такое не замечал

У меня происходит такое же.

Дорабатываю кусок запроса. После динамического обновления выясняется, что допустил глупую ошибку и на запросе вылетает. Захожу, исправляю. Делаю динамическое обновление. Но ошибка свидетельствует о том, что изменения я не сделал. Как же так - я же вижу, что сделал! Делаю трассировку с точкой остановки на выполнение запроса... и о чудо! Когда проверяю содержимое запроса, вижу там... старый вариант! А на экране - новый!.. Делаю шаг на выполнение, вижу знакомую ошибку с выбросом в конфигуратор... в котором уже СТАРЫЙ ТЕКСТ!!! Только что, до остановки по ошибке, там был новый... Выхожу из конфигуратора, захожу... Проверяю, текст старый.

Снова корректирую, СОХРАНЯЮ, выхожу, захожу - текст новый. Запускаю динамическое обновление, дохожу до ошибки, выкидывает в конфигуратор... опять в нём текст старый.

Вот такие вот дела... Обновление кеша помогает, естественно, только на том компьютере, на котором ты его сделал. Но ведь прошлое обновление, в котором я допустил ошибку - накатилось без проблем! А то, в котором я его исправил - ни в какую.

Какие выводы для себя сделал:

1. Если после динамического обновления сразу опять делаешь динамическое обновление (к примеру, сразу обнаружил мелкую ошибку, исправил за секунду и пустил по новому) - жди длительного геморроя.
2. Если столкнулся с такой ситуацией - выхода два: первый (если выгнать всех не представляется возможным) - делать обновление кеша на том компьютере, на котором работают с исправленным модулем, молясь Ктулху, чтобы никто другой пока туда не лез; второй - выгонять всех и делать обновление не динамически, после чего произвольное количество времени (не прогнозируемо) динамическое обновление начинает работать правильно.

Есть еще два очень важных совета, которые я сформулировал опытным путём (не относятся прямо к описываемому глюку, а касаются всего опыта работы с 8.2-8.3):
1. Динамическое обновление после выхода из клиента имеет очень высокие шансы пройти с ошибкой; наоборот, обновление с трассируемым клиентом, который вы соглашаетесь для обновления закрыть по просьбе конфигуратора, имеет крайне низкие шансы пройти с проблемами.
Хотя по элементарной логике должно быть наоборот).
2. Если клиент после динамического обновления не грузится, создаю любую константу, удаляю её и обновляюсь по-новой (даже динамически).
3. Повторюсь! Не обновляться динамически сразу же после динамического обновления! Пойдите покурите или сделайте себе чай. После чего обновляйте. Возможно, проблема касается 1 минуты, возможно чуть больше, но, похоже, что при двух повторных обновлениях подряд мы получаем критическую ситуацию, после которой, не зная пункта 2. можно остановить работу всего предприятия.

Проблема была обнаружена на 8.3.10.2466 и 8.3.11.2867; раньше даже не подозревал о возможности такого.

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

в старых версиях 1С при динамическом обновлении ВСЕГДА задавался вопрос - "Перезапустить конфигуратор" (да/нет)
при нажатии НЕТ - просто закрывался конфигруратор.
при нажатии ДА - перезапускался.

а вот в новых версиях - такого вопроса НЕТ. и как показывает практика - очень даже зря.

так вот - я просто начал самостоятельно перезаходить в конфигуратор после каждого динамического обновления - ПОМОГЛО

P.S. дабы развеять все сомнения - несколько раз я обновлялся динамически без перезапуска конфигуратора - в итоге получал:
- на экране - код, который только что написан
- а в "реале" - код, который был до изменений.

Вывод - нужно просто перезапускать конфигуратор после КАЖДОГО динамического обновления.

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

Аналогичная проблема: пропадают изменения после динамического обновления.
SQL:2014
Платформа: 8.3.11.2867, ранее была 8.3.10.2505

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

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

Тоже пропал код . Версия платформы 1С:Предприятие 8.3 (8.3.10.2650)
Делаю регулярно выгрузки в cf.
Сравнение с последним сохраненным cf - не выявлено различий.
Смотрю вручную - различия вижу .
Добавляю в модуль один пробел , сохраняю, сравниваю с cf - только после этого стали видны отличия.

Имхо глюки платформы. И да - сохранялся динамически, так как в базе работают тестировщики.

Видимо косяк платформы все же.

8.3.10.2466 - локальная файловая база. Периодически возникают ошибки, то модуля нет, то картинки в библиотеке картинок, но чистка кеша (удаление/добавление базы) исправляет ситуацию. Все таки ИМХО платформа версии не удачная.

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

Добрый день. у меня такая же проблема. Версия платформы 8.3.10.2252 поменял в конфигурации режим совместимости с 8.2 на 8.3.9 и уже пару дней косяков нет. Попробуйте может и вам поможет

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

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

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