Как устранить циклическое обновление и ошибку доступа при запуске 1С 7.7 Торговля и Склад

← На главную

Ситуация, когда при каждом запуске 1С:Предприятие 7.7 конфигурация «Торговля и Склад» пытается выполнить автоматическое обновление, является классической технической проблемой, связанной с аварийным завершением работы системы. Рассмотрим подробно, почему это происходит, как работает механизм проверки релиза и какими способами можно вернуть систему в рабочее состояние, чтобы пользователи могли заходить в базу без прав администратора.

Разберем механизм проверки необходимости обновления

Для начала проанализируем, как платформа 1С 7.7 понимает, что базе данных требуется программное обновление. В типовой конфигурации «Торговля и Склад» (ТиС) эта логика жестко прописана в Глобальном модуле. При каждом запуске программы срабатывает предопределенная процедура ПриНачалеРаботыСистемы. Внутри этой процедуры система сравнивает текущее значение константы НомерРелиза с тем номером, который указан разработчиком в свойствах самой конфигурации (поле «Комментарий»).

Давайте посмотрим на пример кода, который обычно отвечает за этот процесс в глобальном модуле:


// Если пустое значение Константа.НомерРелиза, то это первый запуск конфигурации
ЭтоПервыйЗапуск = ПустаяСтрока(Константа.НомерРелиза);

Если Константа.НомерРелиза <> Лев(Метаданные.Комментарий, 8) Тогда
    ФлагЗапускаНастроек = 0;
    Если ПравоДоступа("Использование","Обработка.ОбновлениеИБ") = 1 Тогда
        ОткрытьФормуМодально("Обработка.ОбновлениеИБ", ФлагЗапускаНастроек);
    Иначе
        Предупреждение("Первый запуск программы для обновления информационной базы |должен произвести пользователь с правами администратора!", 60);
        СтатусВозврата(0);
        Возврат;
    КонецЕсли;
КонецЕсли;

Если эти значения не совпадают, система делает вывод: структура данных (метаданные) изменилась, а сами данные еще не были обработаны соответствующими скриптами. В этот момент запускается специализированная обработка ОбновлениеИБ. Именно поэтому обычные пользователи (продавцы, кассиры) не могут войти в программу — у них просто нет прав на запуск этой обработки или на изменение системных констант, которые она перезаписывает.

Выясним причину «зацикливания» обновления

Проанализируем ситуацию автора: компьютер выключился прямо во время загрузки 1С. Это критический момент. Процесс обновления в 1С 7.7 состоит из последовательных шагов. Система обновляет константу НомерРелиза только после успешного завершения всех процедур модификации документов и справочников. Если в процессе произошел сбой (выключился свет или возникла ошибка «Номер не уникален»), константа остается старой. Следовательно, при следующем запуске проверка в ПриНачалеРаботыСистемы снова видит несоответствие и снова пытается запустить обновление. Получается замкнутый круг.

Шаг 1: Восстановление физической целостности базы данных

Прежде чем вносить изменения в код или константы, мы обязаны убедиться, что файлы базы данных не повреждены. Аварийное выключение часто приводит к порче индексных файлов (*.cdx). Рассмотрим последовательность действий в Конфигураторе:

Запустим 1С:Предприятие в режиме Конфигуратор.
Перейдем в меню Администрирование — Тестирование и исправление ИБ.
Установим флажки на пунктах «Реиндексация таблиц» и «Проверка физической целостности».
Нажмем кнопку «Выполнить».

Важно: Реиндексация исправит ошибки, из-за которых система может выдавать сообщение о «неуникальности номера» при попытке модификации документов в ходе обновления.

Шаг 2: Устранение ошибки «Номер не уникален»

Если после реиндексации обновление все равно прерывается с ошибкой уникальности номера, нам нужно понять, какой именно объект вызывает конфликт. Чаще всего при обновлении ТиС происходит перенумерация или программное создание новых видов документов. Если в базе уже есть документы с «кривыми» номерами (например, введенными вручную с лишними префиксами или символами), автонумератор 1С может споткнуться.

Рассмотрим, как найти виновника:

Зайдем в базу под пользователем с полными правами (Администратор).
Дождемся запуска обновления и внимательно посмотрим на строку состояния или сообщения в окне. Там обычно указывается тип документа, на котором произошел сбой.
Проанализируем последние введенные документы этого типа через Журнал документов.
Если найдены дубли или номера, нарушающие логику (например, вместо 00001 стоит 99999), их необходимо исправить вручную.

Шаг 3: Ручная корректировка константы (быстрое решение)

Если мы понимаем, что обновление не несет в себе критических изменений учетной политики, а лишь «зависло» из-за технического сбоя, можно применить метод ручного исправления. Это позволит пользователям войти в систему немедленно. Посмотрим, как это сделать:

Зайдем в программу под Администратором.
Откроем меню Операции — Константы.
Найдем в списке константу Номер релиза.
Впишем в нее актуальное значение. Чтобы узнать его, откроем в Конфигураторе свойства конфигурации и скопируем первые 8 символов из поля «Комментарий» (например, 7.70.985).

Внимание: Этот способ считается «грязным», так как если обновление должно было изменить алгоритмы расчета налогов или движений по регистрам, эти действия выполнены не будут, что может привести к ошибкам в учете в будущем. Используйте этот метод только в крайнем случае, если уверены в стабильности данных.

Шаг 4: Анализ кода обработки «ОбновлениеИБ»

Программисту рекомендуется открыть обработку ОбновлениеИБ (она находится в дереве метаданных на вкладке «Обработки»). Рассмотрим её основной модуль. Ищите процедуру глОбновитьИнформационнуюБазу. Именно здесь прописаны условия, которые выполняются при переходе с одной версии на другую.

Иногда полезно временно закомментировать участок кода, вызывающий ошибку «Номер не уникален», если этот участок не критичен для текущего учета, дать обновлению завершиться, а затем вернуть код обратно и исправить данные вручную. Однако, это требует глубокого понимания логики Trade and Warehouse.