1с ошибка при обновлении wscript
При запуске одной из информационных баз в режиме предприятия тонкий клиент падает с ошибкой.
В эту инф базу можно зайти под другим пользователем инф базы
Тот же пользователь сети - не пользователь инф базы- может запустить другую информационную базу.
Кэш чистил - ниже код
If Exist %USERPROFILE%\AppData\Roaming\1C\1Cv8 (
rem Удаляются все файлы в Windows7 или Windows8
Del /F /Q %USERPROFILE%\AppData\Roaming\1C\1Cv8\*.*
Del /F /Q %USERPROFILE%\AppData\Local\1C\1Cv8\*.*
rem Удаляются все каталоги в Windows7 или Windows8
for /d %%i in ("%USERPROFILE%\AppData\Roaming\1C\1Cv8\*") do rmdir /s /q "%%i"
for /d %%i in ("%USERPROFILE%\AppData\Local\1C\1Cv8\*") do rmdir /s /q "%%i"
)
В журнале Windows имя сбойного модуля core83.dll .
Проявляется как для 32 битного, так и 64- битного приложения платформа 8.3.10.2561.
Платформу 32 переустанавливал- не помогает
Под этой платформой работали несколько месяцев :(
(30) обновиться до 8.3.11. у меня было несколько баз, в которые нельзя зайти ни под одним пользователем в режиме предприятия. Под 8.3.11- все работает.
А проблема точно не в базе? Встречал случаи, когда немного "билась" таблица пользователей и если проблемного пользователя скопировать - то под новым все было нормально.
Такая же проблема, тот же релиз платформы х32, база проверена, кэши чищены, переносил в другую папку, вылет у всех юзеров, кроме одного, независимо от прав.
О_ткат (ох уж этот автоцензор) на предыдущий релиз бухии помогает, так же как установка даты на компе на любое января перед запуском.
Под одним пользователем запускаются все пользователи инф базы.
Если копировать пользователя , под которым запускается, то новый пользователь тоже заходит
(5) в другой конторе с одного компа входит в базу под любым пользователем, на другом ни под одним из тех же.
Пользовательские настройки из режима предприятия чистить пробовали?
Наблюдал подобное поведение как раз в случаях когда пользователь настроил форму под себя, а в конфе она поменялась
(9) поднимать базу с бэкапа и пока не обновлять :(. Потому что все действия по восстановлению - в режиме предприятия
(10), вообще даже в этом случае есть варианты:
1. Зайти в конфигуратор и создать нового пользователя с админскими правами
2. Если база клиент-серверная, то можно в таблице _frmdtsettings поудалять "лишние" строки
(10) как я писал ранее, можно выставить дату на январь и тогда под 3.0.58.20 релизом можно войти (у нас так пока работают).
Такая же ошибка была на 8.3.10.2561 после обновления Бухгалтерии до релиза 3.0.58.20.
Переустанавливали платформу этой же версии на компах пользователей, чистили кэш, обновили до 3.0.58.26 на пустой базе и загрузили конфу в рабочую (где-то тут вычитала такой метод борьбы с подобной ошибкой), дтшник выгружали/загружали обратно, очистили настройки пользователей в самой базе, сделали тестирование и исправление БД, не помогало. В итоге установили новую платформу и все ок.
В описании релиза написано "Внимание! Текущая версия конфигурации "Бухгалтерия предприятия" предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.10.2466.", но если зайти в "Порядок обновления", есть запись "Рекомендуется использовать версию 1С:Предприятие 8.3 не ниже 8.3.10.2667.".
А вот нам все вышеперечисленное не помогло. Причем падал тонкий и толстый клиент при подключении только к одной определенной 1с sql базе. Ко второй - успешно подключался.
Но мы нашли неожиданное решение.
Сначала проверили на чистом свежесозданном Windows профиле на том же компе - все работает.
Дальше начали шерстить профиль - что же может ломать 1С (напомню, стандартная очистка, описанная выше, не помогла).
Запустили Process monitor, записали что делает 1c при запуске.
В итоге выяснилось, что перестала работать 1С 1.02.2018 на тех компах, на которых стоит КриптоПро и были установлены личные сертификаты с алгоритмом ГОСТ!
Для временного решения - сложите все файлы сертификатов из "C:\Users\username\AppData\Roaming\Microsoft\SystemCertificates \My\Certificates" в другую папочку и 1С заработает.
После запуска 1С, можно сложить серты обратно, она уже не падает. Полтора дня убили на эту тряхомундию. =((
alk; /Sergeant/; freddy_kind; arakelyan; izidakg; Kirich2; PANovikov; user926700; elona; AVKonya; Pafnytich; Gravern; extralook; Мах; ovchinnicov; user705522_constantin_h; Alister; t.v.s.; + 18 – Ответить
(18) интересно, как это связано с датой 1 февраля? В одной конторе возможно из-за этого. но вот в другой, там где с пяти из шести компов не входит, там-то криптопро стоит только у главбуха.
(18)
Забыл код на PowerShell приложить - маленький workaround, пока 1С фиксит. Скрипт убирает серты, запускает 1С, кладет серты обратно. Главное - не тяните с выбором базы, а то скрипт ждет всего минуту и возвращает серты. =)
(73) это не вин проблемы. На моем компе нет никакого КриптоПро ,тем не менее , у меня была проблема и я создал этот пост
(21)
Все равно проверьте наличие сертификатов даже если и нет крипто про. Там могут быть и RSAшные серты и ГОСТовые.
Нам это помогло и сейчас наш франчайзи оформляет багу в 1С, посмотрим как они отреагируют.
У меня та же проблема платформа 10.2561 БП 3.0.58.26.
Вопрос возникает, если дело в сертификатах, то причем тут релиз базы. Получается в прошлым релизам не мешали сертификаты?
Попробовал остаться на 8.3.10, так вот подошла 8.3.10.2667, а более поздняя 8.3.10.2699 не подошла, но по причине того, что периодически на полностью здоровой базе вываливалась с ошибкой о нарушении структуры.
Тоже после обновления на БП 58.20 такая же ерунда. Методом тыка выяснилось. что если отключить у пользователя начальную страницу, которая там по умолчанию идет, то всё работает. Как только пользователь добавляет себе начальную страницу, то сразу всё падает. Это только на компе где есть эти сертификаты.
(30) обновиться до 8.3.11. у меня было несколько баз, в которые нельзя зайти ни под одним пользователем в режиме предприятия. Под 8.3.11- все работает.
(30)на другом компе зайти, если, конечно, есть в сети еще 1с. Заметил, что если в этой начальной странице не указана Организация, то тоже нормально. 1С валится, после установки организации там.
(34) так и пришлось, зашел с единственного компа, не подверженного вылету, под админом и через Производительность отключил эту начальную страницу.
Нашел, надо проверить
Пользователь с полными правами может отключить отображение начальной страницы для определенных пользователей программы «1С:Бухгалтерия 8» редакции 3.0 (в том числе и для себя), которым не требуется отслеживать общие показатели деятельности организации, выведенные на рабочий стол.
Настройка отображения начальной странице находится в форме Производительность, доступ к которой осуществляется по одноименной гиперссылке из раздела Администрирование.
Для выборочного отключения отображения начальной страницы при установленном флаге Показывать начальную страницу следует перейти по ссылке Всем пользователям и отключить флаги для определенных пользователей.
По-моему, гораздо важнее, чем просто обновление платформы на крайний релиз, было определение причины, почему 1С вылетает (из-за сертификатов, как почти у всех в этой теме), а уже зная эту причину, можно подобрать для себя решение.)
Есть рабочая база БП КОРП (клиент-сервер), релиз 3.0.58.41. Все заходят, никаких проблем. Платформа 8.3.10.2505.
Сегодня развернул еще одну, чистую (клиент-сервер на тех же серверах) и получил аналогичную ошибку. Вылетает у всех пользователей, не зависимо установлен КриптоПро или нет. Стабильно работает только если запустить клиента на самом сервере 1С.
В итоге просто отключил начальную страницу в форме Производительность (по совету 31) и заработало у всех пользователей. Потом обновлю платформу до последнего релиза 8.3.10 и снова попробую вернуть начальную форму.
Это повезло еще, что есть пользователь, под которым можно зайти в базу. У меня было несколько баз, где никто не мог зайти
Сначала убрал сертификаты в другую папку - база запустилась. Потом положил их обратно и обновил платформу до 8.3.11.3034 - база перестала открываться. Возврат на старую платформу и перемещение сертификатов не помогает. Создавал базу заново с загрузкой из dt - всё равно не работает, при этом все базы более старых релизов работают нормально.
Почистил кэш перед установкой 8.3.11.3034 - не помогло. Заметил, что на 11 платформе в журнале ошибок краш ругается не на Core83.dll, а на mngui.dll. Запустился под толстым - и о чудо!
Под толстым клиентом на 8.3.11.3034 работает нормально!
После однократного запуска под толстым клиентом, тонкий клиент восстановил работоспособность!
Сегодня, сразу на трёх компьютерах такой же глюк, я убираю с другого компьютера, под этим пользователем информационную панель, база стартует, но когда в задачах выбрать, список задач, вылетает((
Какая может быть связь сертификатов с определёнными пользователями?
Да не сертификатов, а платформы.
Сертификаты здесь сбоку-припеку, просто на них вылезло.
А так - ошибка в dll-ке возникает.
В прежней платформе "старая" DLL, она, видимо, с "новым" механизмом запроса сертификатов неправильно работает.
Предположительно глюк связан с отображением какого то графического элемента на некоторых интегрированных видеокартах с включенным аппаратным ускорением.
Но это сугубое имхо
(52) а если документы в базу вводятся в онлайн режиме, причем не через Предприятие и пользователя? ))
Точнее, не "этого самого" пользователя ))
(54) ну, если вам дадут "отключить" многосторонний обмен. )))
Особенно бухгалтерия будет на вашей стороне ))
(55) я думаю что тут слишком много если, ели не надут то будут сидеть у монитора и курить бамбук (хотя решение я Вам выше написал как можно сделать (через виртуалку))
(53) еще как вариант и у нас он прокатил это создать виртуалку и с нее сделать все танцы с бубном по отключению новостей, либо взять старую машину на которой можно отключить аппаратное ускорение
(56) раз для вас много "если" - то самый лучший вариант, это обновиться на новую платформу.
Только и всего ))
И не нужно будет ничего выдумывать более того.
Кто вам это предложил? Вот ему и напишите, что "не решило" ))
Я же говорил - за версию 8.3.11. 3034 ))
Я предположил, что в 8.3.11 все решили, но рекомендовал - 8.3.11.3034.
Если ранние версии не решают проблемы - что ж, обидно, печально, досадно, но ладно ))
Это - 1С, тут и не такое возможно ))
Еще раз столкнулся с этой же проблемой, при этом возврат даты назад не помогал решить проблему, помогло создание нового пользователя в конфигураторе и отключение начальной страницы уже через него у всех. (Бухгалтерия 3.0) Может гуру напишут программу отключающую начальную страницу. что-то типа патча.
(63) причем тут "гуры", все давно написано уже)
Вы суть поймите - как вы обработку запустите, если не запустите Предприятие?
Менять ради этого конфу -> прописывать сброс начальной страницы?
Или искать и вклиниваться в какое-нибудь задание?
Проще обновиться, чем заниматься совершенно бессмысленным делом ))
(65)ну, разве что получите массу других ошибок, из-за чего, собственно, мы и перешли на новый релиз )
(66)есть ситуации когда смена релиза, особенно крайнего не всегда возможна.
Это 1с может позволить себе менять релизы платформы каждые 2 недели. У нас такой возможности нет.
(67) у нас смена релиза занимает день, хотя и не так много чего по пользователям.
А вот вокруг 1С много чего наверчено, что перестает работать при смене релиза )
Была такая же ошибка, 1С напрочь отказывалась запускаться, сразу при открытии вываливалась с ошибкой "программа будет закрыта". Причем только на одной базе. Единственное отличие этой базы от других - в ней настроена синхронизация с ЗУП 3.1, в остальных нет.
Прошли все круги ада - ТИИ, chdbfl, чистка кэша, чистка временных файлов, перемещение базы в другой каталог, выгрузка-загрузка .dt, обновление до последнего релиза (3.0.59.45).
Наконец додумались зайти в базу под давно не использовавшимся пользователем. И, о чудо, база открылась. Отключили, как здесь рекомендовалось, начальную страницу. И остальные пользователи смогли зайти.
Вопрос - что это было? Галка "Показывать начальную страницу" стояла "для всех пользователей". Если дело в ней, почему одному пользователю все-таки удалось зайти? Может это быть как-то связано с синхронизацией?
-------------------------------------------------------------------------------------------------------------------------------------
Сигнатура проблемы:
Имя события проблемы: APPCRASH
Имя приложения: 1cv8c.exe
Версия приложения: 8.3.10.2561
Отметка времени приложения: 5983aaba
Имя модуля с ошибкой: core83.dll
Версия модуля с ошибкой: 8.3.10.2561
Отметка времени модуля с ошибкой: 5983a625
Код исключения: c0000005
Смещение исключения: 00009592
Версия ОС: 6.1.7601.2.1.0.16.7
Код языка: 1049
Дополнительные сведения 1: 0a9e
Дополнительные сведения 2: 0a9e372d3b4ad19135b953a78882e789
Дополнительные сведения 3: 0a9e
Дополнительные сведения 4: 0a9e372d3b4ad19135b953a78882e789
Как правило, ошибка возникает при фоновом обмене данными между базами 1С или запуске синхронизации вручную. Что делать при появлении этой ошибки и куда смотреть.
Текст: «Ошибка при вызове конструктора (COMObject) по причине: -2147221005(0x800401F3): Недопустимая строка с указанием класса».
Решение — в регистрации библиотеки comcntr.dll из каталога программы для корректного вызова COMConnector.
Подготовительные действия
- отключите службу Агента сервера 1С:Предприятия и программы, возможно использующие регистрируемую DLL;
- если ранее использовалась библиотека устаревшей версии, удалите регистрацию comcntr.dll, запустив команду вызова regsvr32 с ключом /u.
Подходы к решению
В командной строке с правами Администратора выполните команду:
2. Переустановка платформы с внесением исправлений
- запускаем консоль «Службы компонентов»;
- добавляем новый элемент, переходим «Компьютеры» — «Мой компьютер» — из списка выбираем «Приложения COM+»;
- выбираем «Создать» — «Приложение»;
- в Мастере установки выбираем второй вариант «Создать новое приложение», в поле «Введите имя нового приложения:» вводим «V83COMConnector», «Способ активации» устанавливаем «Серверное приложение», нажимаем «Далее»;
- выбираем учетную запись под которой запускается приложение, по умолчанию — «Текущий (вошедший в систему) пользователь»;
- на этапах «Добавление ролей приложения» и «Добавление пользователей для ролей» нажимаем «Далее», а затем «Готово».
В ветке только что созданного приложения переходим в подветку «Компоненты» и создаем компонент:
- в контекстном меню выбираем «Создать» — «Компонент»;
- кликаем по первому варианту «Установка новых компонентов»;
- в открывшемся диалоге выбираем необходимый файл comcntr.dll и нажимаем «Открыть»;
- нажимаем «Далее» и «Готово».
Обратите внимание: после установки измените свойства объекта. Для этого переходим к ветке V83COMConnector:
- открываем свойства созданного компонента, переходим в ветку V83COMConnector — «Свойства»;
- на вкладке «Безопасность», в «Авторизация» снимаем флаг «Принудительная проверка доступа для приложений»;
- в «Политика программных ограничений» устанавливаем флаг «Применить политику программных ограничений» и выбираем «Уровень ограничений:» — «Неограниченный»;
- нажимаем «Применить» — «ОК».
Полная версия со снимками экранов — в статье на Дзен-канале.
При автоматическом обновлении 1С Бухгалтерия версий 3.0.75.100 Платформа 8.3.16.1224 происходит зацикливание.
Происходит периодическое сохранение базы, загрузка обновления -после вылетает и все повторяется. Это происходит и на Windows 7 и с другими базами в Windows 10.
Вот лог:
27.02.2020 09:25:53 Используется COM соединение: true
27.02.2020 09:25:53 Запускается: regsvr32.exe; параметры: /n /i:user /s "C:\Program Files\1cv8\8.3.16.1224\bin\comcntr.dll"; окно: SW_HIDE; ожидание: true
27.02.2020 09:25:53 Код возврата: 0
27.02.2020 09:25:53 Файл скрипта: C:\Users\RashidViktorovich\AppData\Local\Temp\1Cv8Update.200227092059\splash.ht
27.02.2020 09:25:53 Количество файлов обновления: 1
27.02.2020 09:25:53 1. D:\Base\tmplts\1c\Accounting\3.0.75.104\1cv8.cfu (Обязательная)
27.02.2020 09:25:54 Завершение работы пользователей.
27.02.2020 09:25:56 Создание резервной копии информационной базы.
27.02.2020 09:25:57
Выполняется копирование из:
D:\Base\ГранитСтрой\1Cv8.1CD
в:
D:\Base\Архив\Гранит_Строй\1Cv81582759553483.1CD
27.02.2020 09:26:04 Резервная копия базы создана
27.02.2020 09:26:07 Загрузка файла обновления в основную базу (1/1).
27.02.2020 09:26:08 Запускается: C:\Program Files\1cv8\8.3.16.1224\bin\1cv8.exe; параметры: CONFIG /F"D:\Base\ГранитСтрой" /N"" /P"******" /WA- /UpdateCfg "D:\Base\tmplts\1c\Accounting\3.0.75.104\1cv8.cfu" /Out "templog.txt" /UCПакетноеОбновлениеКонфигурацииИБ /DisableStartupMessages /DisableStartupDialogs; окно: SW_SHOW; ожидание: true
27.02.2020 09:28:24 Код возврата: 0
Обновление конфигурации успешно завершено
27.02.2020 09:28:25 Обновление конфигурации информационной базы (1/1).
27.02.2020 09:28:26 Запускается: C:\Program Files\1cv8\8.3.16.1224\bin\1cv8.exe; параметры: CONFIG /F"D:\Base\ГранитСтрой" /N"" /P"******" /WA- /UpdateDBCfg -server /Out "templog.txt" /UCПакетноеОбновлениеКонфигурацииИБ /DisableStartupMessages /DisableStartupDialogs; окно: SW_SHOW; ожидание: true
27.02.2020 09:29:09 Код возврата: 0
Обновление конфигурации базы данных
Обработка структуры базы данных.
Сбор служебной информации.
Обновление конфигурации базы данных успешно завершено
Построение индекса справки.
27.02.2020 09:29:10 Выполнение обработчиков обновления (1/1).
27.02.2020 09:29:11 Запускается: wscript.exe; параметры: "C:\Users\RashidViktorovich\AppData\Local\Temp\1Cv8Update.200227092059\add-delete-patches.js" /ConnectionString:"File='D:\Base\ГранитСтрой';Usr='';Pwd='******';UC=ПакетноеОбновлениеКонфигурацииИБ" /COMConnectorName:"v83.COMConnector" /FixFileNames:"" /RemoveFixNames:"" /Out:"C:\Users\RashidViktorovich\AppData\Local\Temp\1Cv8Update.200227092059\templog.txt"; окно: SW_HIDE; ожидание: true
27.02.2020 09:30:06 Код возврата: -1073741819
27.02.2020 09:30:06 Исключение при вызове ОбновлениеКонфигурацииВызовСервера.ОбновитьИсправленияИзСкрипта: Error, Не удалось обновить исправления конфигурации. Подробности см. в предыдущей записи..
27.02.2020 09:30:07 Завершение с ошибкой. Код ошибки: 2. Подробности см. в предыдущей записи.
27.02.2020 09:30:07 Восстановление информационной базы.
27.02.2020 09:30:07 Восстановление ИБ из временного архива
27.02.2020 09:30:26 База данных восстановлена из резервной копии
27.02.2020 09:30:26 Начат сеанс внешнего соединения с ИБ
27.02.2020 09:30:29 СоединенияИБ.РазрешитьРаботуПользователей()
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
Windows Script Host – особый компонент операционной системы, который позволяет запускать скрипты, написанные на JS (Java Script), VBS (Visual Basic Script) и других языках. При неправильном его функционировании могут наблюдаться различные сбои во время запуска и работы Windows. Такие ошибки зачастую не могут быть исправлены простой перезагрузкой системы или графической оболочки. Сегодня поговорим о том, какие действия необходимо совершить для устранения неполадок в функционировании компонента WSH.Исправляем ошибку Windows Script Host
Сразу стоит сказать о том, что если вы писали свой скрипт и при его запуске получили ошибку, то необходимо искать проблемы в коде, а не в системном компоненте. Например, вот такое диалоговое окно говорит именно об этом:
Такая же ситуация может возникнуть и в том случае, когда в коде имеется ссылка на другой скрипт, путь к которому прописан неверно либо данный файл вовсе отсутствует на компьютере.
Далее мы поговорим о тех моментах, когда при старте Windows или запуске программ, например, Блокнота или Калькулятора, а также других приложений, использующих системные ресурсы, появляется стандартная ошибка Windows Script Host. Иногда подобных окон может появиться сразу несколько. Случается такое после обновления операционной системы, которое может пройти как в штатном режиме, так и со сбоями.
Причины такого поведения ОС следующие:
- Неверно выставленное системное время.
- Сбой в работе службы обновлений.
- Некорректная установка очередного апдейта.
- Нелицензионная сборка «винды».
Вариант 1: Системное время
Многие пользователи думают, что системное время, которое показывается в области уведомлений, существует только для удобства. Это не совсем так. Некоторые программы, обращающиеся к серверам разработчиков или к иным ресурсам, могут работать некорректно или вовсе отказаться функционировать по причине расхождений в дате и времени. Это же касается и Windows с ее серверами обновления. В том случае, если будет расхождение в вашем системном времени и времени сервера, то могут наблюдаться неполадки с апдейтами, поэтому на это стоит обратить внимание в первую очередь.
- Нажимаем на часы в правом нижнем углу экрана и переходим по ссылке, указанной на скриншоте.
Теперь ваше системное время будет регулярно синхронизироваться с сервером времени Майкрософт и расхождения не будет.
Вариант 2: Служба обновлений
Windows – это очень сложная система, с множеством одновременно протекающих процессов, и некоторые из них могут повлиять на работу службы, отвечающей за обновление. Высокое потребление ресурсов, различные сбои и занятость компонентов, помогающих апдейту, «заставляют» службу совершать бесконечные попытки выполнить свою работу. Сам сервис также может сбоить. Выход здесь один: отключить его, а затем перезагрузить компьютер.
-
Вызываем строку «Выполнить» сочетанием клавиш Win+R и в поле с названием «Открыть» пишем команду, которая позволит получить доступ к соответствующей оснастке.
Если после выполненных действий ошибки продолжают появляться, то необходимо поработать с уже установленными обновлениями.
Вариант 3: Некорректно установленные обновления
Данный вариант подразумевает удаление тех обновлений, после установки которых начались сбои в Windows Script Host. Сделать это можно как вручную, так и с помощью утилиты восстановления системы. В обоих случаях необходимо вспомнить, когда «посыпались» ошибки, то есть после какой даты.
-
Идем в «Панель управления» и находим апплет с названием «Программы и компоненты».
-
Для перехода к данной утилите кликаем правой кнопкой мыши по значку компьютера на рабочем столе и выбираем пункт «Свойства».
Вариант 4: Нелицензионная Windows
Пиратские сборки «винды» хороши лишь тем, что они совершенно бесплатны. В остальном же такие дистрибутивы могут принести массу проблем, в частности, некорректную работу необходимых компонентов. В этом случае рекомендации, приведенные выше, могут не сработать, так как файлы в скачанном образе уже были сбойными. Здесь можно только посоветовать поискать другой дистрибутив, но лучше воспользоваться лицензионной копией Windows.
Заключение
Решения проблемы с Windows Script Host довольно просты, и с ними справится даже начинающий пользователь. Причина здесь ровно одна: некорректная работа инструмента обновления системы. В случае с пиратскими дистрибутивами можно дать следующий совет: пользуйтесь только лицензионными продуктами. И да, правильно пишите ваши скрипты.
Мы рады, что смогли помочь Вам в решении проблемы.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.
Читайте также: