Зайти в конфигуратор нельзя , при попытке зайти в конфигуратор пишет нарушена целостность конфигурации .
Архив на утро есть .
Что порекомендуете в данной ситуации ?

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

Странный вопрос
Восстановить из архива

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

Люди делятся на тех,кто уже делает бэкапы,и прочих.Демоническое обновление это зло.

(0) Суперграмотный преподаватель на курсах сказал, что он постоянно пользовался динамическим обновлением и вот на 1001 раз он так же запорол базу Аэрофлота. Ему пришлось обратиться к еще более грамотному гуру, который при помощи редактирования в шестнадцатеричной системы исчисления, ассемблера и чуда восстановил базу. После этот преподаватель никогда не использовал "Динамическое обновление"

(0) База файловая, MS SQL, Оракл или другое?

(6)
Появилась критичная ошибка. Варианты решения? Выгнать всех 1000 пользователей на 20 минут из базы для обновления?
Понятное дело чтобы не появлялась ошибка необходимо нанять тестировщиков, но вот без них как быть?

(7) Для систем 24/7 существует решение от 1С которое позволяет обновлять не через динамическое обновление и не выгоняя пользователей, но это какое то очень муторное, но типовое решение платформы

1. почистить кеш
2. в скуле почистить ConfgiSave
3. Если не помогает - то уже выше написано

(7) Нанять программистов, которые делают минимум ошибок.

Начать с (3)

(8) Какое решение?

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

(10) Дешевле марсиан дождаться

(0) Нужно попробовать почистить кэш 1С. Если не поможет, то читаем дальше.

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

Выяснилось, что все измененные объекты конфигурации программа хранит в таблице configsave. Но в моем случае табличка оказалась пустая. При обновлении конфигурации программа снача копирует все изменения из таблицы configsave в таблицу config, затем очищает первую.

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

Если в таблице configsave есть данные, то таблицу нужно очистить: delete from configsave
delete from config where FileName = 'commit'
delete from config where FileName = 'dynamicCommit'
delete from config where FileName = 'dbStruFinal'


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

Для этого выполним следующий запрос:

USE [ИмяРабочейБазы]
DELETE FROM [DBO].[ConfigSave]
DELETE FROM [DBO].[Config]
INSERT INTO [ИмяРабочейБазы].[Dbo].[Config] SELECT * FROM [ИмяКопииБазы].[Dbo].[Config]
GO

(12) Вроде вот это, но наш подрядчик почему то отказался от этого решения и останавливает базу для обновлений https://xn--1--rlchba2deh.xn--p1ai/обновление_информационных_баз_1с_в_пакетном_режиме

(5) Не трынди))),у Аэрофлота не было базы на 1С.Никогда.

Байка про базу Аэрофлота напомнила другую байку: https://cs10.pikabu.ru/post_img/2020/03/01/4/1583041978111861808.png

(17) Ну или у Победы, в общем в этой экосистеме авиакомпаний. Не трындю, препод не стал бы на сертифицированном курсе от 1С перед 30 слушателями козырять тем, что нет на самом  деле и легко проверить

(7) >> Появилась критичная ошибка. Варианты решения? Выгнать всех 1000 пользователей на 20 минут из базы для обновления?

1. Если ошибка действительно критичная (что в реальной жизни случается крайне редко), то да - выгнать всех (пусть хоть 100500) пользователей на какое-то время (как правило достаточно и 3-5 минут, если не идёт речь о реструктуризации БД).

2. Если ошибка не критичная (это ~99.9% проблем), то исправление вполне может дождаться технологического окна (как правило, вечером или ночью в период наименьшей нагрузки).

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

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

(16)
Не похоже.
Это похоже на автообновление, но ни как на "динамо" без "динамо".
Она поможет обновить 100 типовых баз, но ни как не "срочное динамо" когда выбираешь объекты из хранилища которые обновлять.

Так и у нас есть в выходные ночью "окно" в пересменку склада на полное обновление. Но вот после этого "полного" обнавления вылазят косяки что напрограммировали за неделю, и без динамо не обойтись. А понедельник ещё такой день, когда после выходных все усиленно работают, вообще беда =)

а если просто загрузить конфу командной строкой?

(21) а вы разве не тестируете у себя, перед тем как обновиться? Есть же пословица: семь раз отмерь - одни отрежь. У вас получается, что кромсаете по живому скрестив пальца и пока везет

(18) Ну и жесток ты батенька.Вроде бы день начинался неплохо,зачем я это прочитал?

(23) а что тестирование дает 100% что не будет ошибок?

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

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

(21) Конечно тестируем, но проскакивает.

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

(17) Байка говоришь? https://www.cnews.ru/news/top/2020-12-24_dochkaloukoster_aeroflota

(17) Байка говоришь? https://solutions.1c.ru/projects/69945/

(29) Вот когда внедрят)))

(31) В 2014 году уже внедрили https://www.tadviser.ru/index.php/Проект:Победа_Авиакомпания_(1С:Предприятие_8.3)

(30) Карго совсем не аэрофлот))),только одно название

(28)
И не только к тестированию, но и разработке и учёту.
1С ка же всё стерпит =)

(34) Наша система стоит лицом и к пользователю и к разработчику! А жопа... Жопа где-то глубоко внутри :)

(31) Заставляешь старого человека читать лишнюю для себя информацию:

По словам генерального директора «Победы» Андрея Калмыкова, продукты и решения «1С» авиаперевозчик использовал и до подписания нового соглашения. Какие именно – топ-менеджер не уточнил. Как рассказал CNews представитель «1С», в настоящее время в «Победе» используются система на базе значительно доработанной «1С:Бухгалтерии 8» предыдущей редакции 2.0, а также «1С:Зарплата и управление персоналом Корп» предыдущей редакции 2.5, «1С:Управление холдингом», «1С:Документооборот» и ряд партнерских разработок на платформе «1С:Предприятие 8».

Напомним, что «Победа» – это российский лоукостер, дочернее предприятие группы «Аэрофлот», базирующееся в московском аэропорту Внуково. Компания основана в сентябре 2014 г., чтобы заменить другую «дочку» «Аэрофлота» – «Добролет», прекратившую полеты из-за санкций ЕС.

https://www.cnews.ru/news/top/2020-12-24_dochkaloukoster_aeroflota

(23)
Вы так интересно пишете, как будто мы нанимаем "инопланетян", у нас "Программисты 1с" с большой буквы "П".
Какие есть такие есть, и далеко не худший вариант. Я занимаюсь разными обменами, и общаюсь с программистами других компаний, вижу их творения, и после этого могу сказать что наши 1сники далеко не худшие, а очень даже хорошие.

(21) >> после этого "полного" обновления вылазят косяки что напрограммировали за неделю, и без динамо не обойтись.

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

В большинстве случаев, "без динамо не обойтись" - это миф. Может конечно вы и относитесь к исключениям. Но реально таковые встречаются крайне редко.

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

(36) Не читайте советских газет....,или как там Булгаков писал.

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

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

(40) аппаратку можно мониторить, сервера амортизировать. По регламенту менять комплектующие, а не ждать пока откажет. А с демоническим обновлением, это как с рулеткой.

(39) О, да 1С конвеерно автоматизирует авиакомпании:

По заявлению представителя «1С», у компании есть опыт автоматизации бизнес-процессов российских авиаперевозчиков. Партнеры российского разработчика бизнес-ПО реализовали проекты на базе решений «1С» в авиакомпаниях «Сибирь» (бренд S7 Airlines), «Ютэйр» и «Нордстар».

https://www.cnews.ru/news/top/2020-12-24_dochkaloukoster_aeroflota

(39) Недалек тот день когда 1С будет автоматизировать и западные авиакомпании))

(42) Вот не надо. Аппаратка - это надежная рулетка. Аппаратно реализованная. Секторов добавить можешь, но зеро все равно будет выпадать.

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

Таблицу config взять из бэкапа
Тогда и данные сохранятся, и конфа будет вылечена.
При условии что в бэкапе структура реквизитов не менялась по сравнению с бэкапом.
Делал так пару раз

(21) Нашел! Но это решение только для конфигураций КОРП v8: Что такое фоновое обновление конфигурации базы данных

(43) Шутите,что уж там.Новости все таки не читайте,гастрит или геморой заработаете.

(46) И сколько времени занимает восстановление бэкапа? Это тоже - простой в работе.

(46) >> Уже давно подсчитано.

Тогда не вижу особых проблем. Если конечно посчитали верно.

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

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

(51) А почему Вы не используете это решение? v8: Что такое фоновое обновление конфигурации базы данных

(52) А почему Вы не используете это решение? v8: Что такое фоновое обновление конфигурации базы данных

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

(55)
2-3 мин обновились.
Обычно это так не работает =)

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

(56) у нас выходит 2-3мин. Пользователи могут и не выходить, просто сохраняют что наработали. В кластере грохаются все сеансы и обновляется конфа. Пользователи перезаходят, как написали можно

(57) Какие сознательные пользователи.
Я таких ниразу не встречал.

(58) пару раз заново документ заполнят, после этого становятся сознательными, заранее сохраняют перед обновлением

(59) Завидую про 2-3 минуты((((

Регламент 5 строчек:

1) Пишется письмо на всех за час до обновления. Пользователи готовятся.
2) Пишется письмо непосредственно за 5 минут до обновления.
3) Выгоняются пользователи, блокируется база.
4) Проводится обновления.
5) Пользователи запускаются обратно в базу.

(61) Для конторы человек в 50 пожалуй взлетит

(53) >> А почему Вы не используете это решение? (фоновое обновление конфигурации БД).

Те базы, с которыми я лично работаю, не требуют доступа 24/7. Поэтому просто приняли решение не баловаться в них с динамическим обновлением вообще. Если проблема действительно по-настоящему критичная (случается ну крайне редко), то делаем рассылку на всех пользователей, выгоняем их на 5-10 минут из базы, и обновляем монопольно. Если проблема не критичная, то обновляем вечером в период технологического окна, опять таки монопольно.

Что используют в производственных базах - я не знаю.

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

(57) Копию перед не делаете чтоли?

(43) В крупных организациях живет зоопарк технологий от какой-нибудь простенькой программы на дельфях до SAP ERP.

(61) Вот план в федеральной больнице >200 человек в 1С по обновлению.
1. Написать план обновления, что будет изменено, какие системы затронет, какие отделы, другие подрядные организации.
2. Отдать начальнику ИТ службы.
3. Начальник ИТ, либо его помощница получает визы у других начальников отделов, других подрядных организаций.
4. За день техподдержка рассылает письма с предупреждением.
5. Утром рассылается письмо повторно.
6. За 1 час предупреждают по громкой связи + письменно.
7. За 10 минут предупреждают повторно.
8. Выгнать пользователей.
9. Обновить
10. Разослать письмо в рабочие группы что обновление установлено \ не установлено.
11. Если был запрос на изменение, то подрядные организации проверяют работу API и тп.

Если инцидент, то делается все тоже самое, только в ускоренном темпе, либо устной форме с предупреждением по громкой связи.
Обусловлено тем что либо операции людям делают, либо зарплату начисляют по >5000 сотрудникам медцентра.