1с проверитьбит не определена

Обновлено: 04.07.2024

Причина возникновения ошибки

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

Патчи можно безболезненно устанавливать и удалять (это ведь на самом деле расширения) - причём это можно делать при работающих пользователях.

Установленный патч начинает работать у пользователя только после перезапуска открытой у него базы.

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

И вот если этого не сделать - возникает описанная выше ошибка.

Как устранить возникшую ошибку

Прежде всего обновите ваш обновлятор на последнюю доступную на сайте версию.

Начиная с версии обновлятора от 6 декабря 2019 года я предусмотрел выполнение необходимых процедур при выполнении обработчиков обновления. Эти процедуры удаляют из конфигурации устаревшие патчи (речь идёт о вызове функции 'ИсправленияИзменены' из общего модуля 'ОбновлениеКонфигурации').

Но что делать, если ошибка уже возникла?

Первый способ устранения ошибки

Откройте базу в режиме пользователя.

Если база не запускается в режиме пользователя - удалите проблемное расширение через конфигуратор.

Зайдите в раздел "Администрирование" пункт "Обслуживание":

Далее раскройте подраздел "Обновление программы" и выберите пункт "Установленные исправления (патчи)":

В открывшемся окне удалите все установленные исправления:

После этого перезапустите 1с и убедитесь, что ошибка исчезла.

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

Второй способ устранения ошибки

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

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

Прежде всего обновляем обновлятор на последнюю версию (не ранее 6 декабря 2019 года).

Далее запускаем обновлятор и переходим на закладку "Скрипты":


В этом случае зайдите в дополнительные настройки программы и перейдите на закладку "Интерфейс и общее поведение".

Здесь установите галку "Отображать закладку Скрипты" и установите значение справа в "показывать постоянно".


Указанный скрипт выполнит процедуру удаления устаревших патчей во всех базах.

Для баз, в которых возникли ошибки при выполнении скрипта воспользуйтесь первым способом.

По поводу установки новых патчей

Прямо из обновлятора это можно делать вот так (ссылка).

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

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

Выходит ошибка
Управление автотранспортом Стандарт, редакция 2.0
[16.10.2018 8:55:25]: : Ошибка при вызове метода контекста (Создать): Ошибка инициализации модуля: ВнешняяОбработка.ЗащищеннаяОбработка.МодульОбъекта: : Процедура или функция с указанным именем уже определена (ПроверитьБит)

Что можно сделать?

(1) Автотранспорт переписан, обновлять, так себе, не вариант.
(5) Думаю достаточно "обратиться к поставщику конфигурации".
(7) Это УАТовская система защиты. Надо ломать сначала лицензионные модули, а потом искать откуда они эти модули получает.
(8) но буховский кусок конфигурации, не взирая на то, что в ней сидит УАТ у вас все-таки обновляют. Причем, насколько я сталкивался, если не прав, то поправьте - если вливался УАТ в конфиг с БП, то далее обновления этой соединенной конфиги получают уже от поставщика УАТ, а не с релизов 1С для БП
(8) есть уже функция платформы ПроверитьБит. Поэтому сочувствую.
Файлы защиты для Управление Автотранспортом Стандарт, редакция 2.2, версия 2.2.1.1 может кто прислать?
(11) Насклько знаю есть зашифрованные модули а они вытаскивают код из dll.
Варианты:
1) снизить версию платформы до той, где нет этой функции
2) Снять модуль с поддержки и убрать саму функцию ПроверитьБит из модуля так как она теперь платформенная.
На Рарус надежды мало, ибо у них релизы раз в пол года по УАТ выходят

(15) > снизить версию платформы до той, где нет этой функции

УАТ встроен в БП, для нового релиза БП снизить платформу не получится.

Была практически такая же проблема с УАТом, только с функциями работы с JSON.
Пришлось откатить платформу и запрашивать у поставщика свежий релиз.
(17) А вот это печаль.
Тогда путь один идти и плакать в чатик Раруса.
Иных законных путей нет.
Ну еще можно в УАТе вырезать все вызовы защищенного модуля и надеяться что будет работать в полуобморочном состоянии. В УАТ 1 можно было безболезненно отучить почти везде кроме сложных расчетов рабочего времени и расхода ГСМ.
(20) Насколько я понимаю обращение к этим процедурам идет из защищенных модулей.
(20) Не будут работать очтеты УАТ все
+ не все документы будут открываться.
ТО есть УАТ как бы есть, но работать в нем не получится, тоже так себе решение
(21) Даже если их вскроешь, тебе это не поможет. Ибо работать в базе не получится

Ну и что за чушь, относительно того, что нет релиза, нет релиза?

Управление автотранспортом Стандарт, редакция 2.1 2.2.1.1 25.09.18

Это в выпусках релизов ИТС - есть право на обновление, то обновляешься нормальным способом.

Обращаю внимание, что Дата выпуска релиза соотв. выпуску

Внимание! Текущая версия конфигурации "Бухгалтерия предприятия" предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.12.1529.

Методика расследования причин медленной работы операции на примере открытия управляемой формы

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

Сбор и анализ стандартных данных

Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".

Мы организовали тестовый стенд, на котором наша проблема воспроизводится под пользователем с полными правами. К этому стенду мы можем подключаться как напрямую с удаленной рабочей станции в режиме тонкого клиента, так и в режиме веб-клиента через публикацию на веб-сервере.

Настройка технологического журнала на клиенте может быть такой:

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).

После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.

Замеры времени средствами БСП будут выглядеть следующим образом:


Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.

Замер отладчиком конфигуратора изображен на следующем рисунке:


Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.

'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000

а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).


Точное время начала замера (минут:секунд.миллисекунд): 25:10.779


Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801

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


Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.

Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.

Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:

  • Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
  • Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.

Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:


После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).

После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:


По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.

Запомним этот результат и проанализируем траффик.

Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.

При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:


Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.

Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:


В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.

После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.

Подведем промежуточный итог:

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

Из всех этих пунктов для нас наиболее полезным и требующим дополнительного анализа является тезис "Размер пакета с формой подозрительно велик".
Какие могут быть причины для такой ситуации? В общем случае их несколько:

  • Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
  • Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
    • Хранилище значения, Строка(0);
    • Большие коллекции (Таблица, Дерево, Список);
    • Произвольный тип (концентрация проблем).

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

    Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:


    Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
    Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:


    И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:


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

    Отключив заполнение данных реквизитов, убеждаемся, что проблема с производительностью формы исчезает, что значит, что причина была найдена правильно.

    Выводы и рекомендации

    Длительная работа открытия формы обусловлена сериализацией и десериализацией больших коллекций значений при передаче их между клиентом и сервером.

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

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


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

    Помог совет хорошего человека alex0402 на дружественном форуме:

    1) почистить кеш;
    2) удалить базу из списка и добавить снова.

    Проблема решена, тему можно закрывать.

    fisher8282 , интересно стало, что же за дружественный форум? Везде написал, что помог и везде этот секретный дружественный форум?
    Уже не интересно.

    Помог совет хорошего человека alex0402 на дружественном форуме:

    1) почистить кеш;
    2) удалить базу из списка и добавить снова.

    это, т.е. этот вопрос, просто несерьёзно.
    Чистка кэша - стандартные действия, которые надо делать после/при обновлении.
    И все делают

    Если Вы воспользуетесь обновлятором 1С (есть такая б/п программа в интернете), то там эти действия - чистка кэша - встроены в процесс (автоматического) обновления

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

    И вопроса не было бы

    Помог совет хорошего человека alex0402 на дружественном форуме:

    1) почистить кеш;
    2) удалить базу из списка и добавить снова.

    это просто несерьёзно.
    Это стандартные действия, которые надо делать после/при обновлении

    Если Вы воспользуетесь обновлятором 1С (есть такая б/п программа в интернете), то там эти действия - чистка кэша - встроены в процесс (автоматического) обновления

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

    И вопроса не было бы

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

    Цитата

    fisher8282 , интересно стало, что же за дружественный форум? Везде написал, что помог и везде этот секретный дружественный форум?

    Да не секретный он: forum-1c_ru. Обычно не приветствуют ссылки на другой ресурс.
    forum-1c_ru/index.php?topic=67815

    Читайте также: