Почему в 1С 7.7 не удаляются помеченные на удаление документы и как это исправить

← На главную

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

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

Выясняем причины: почему документы «исчезают» из обработки удаления

Прежде всего, нам необходимо понять механику работы платформы 7.7. Список объектов для удаления строится на основе сканирования системного файла 1SJOURN.DBF (общий журнал документов) и анализа поля ISMARK. Если база данных имеет повреждения на физическом или логическом уровне, стандартные механизмы поиска ссылок начинают давать сбой.

Проанализируем основные факторы, приводящие к такой «невидимости» документов:

Нарушение индексов: Самая простая причина, при которой индексные файлы (.CDX) перестают соответствовать данным в таблицах (.DBF).
Повреждение признака удаленности: В формате DBF каждая запись имеет технический байт, определяющий, помечена ли запись как «удаленная» на уровне файловой системы. Если там появляется «мусор» (некорректные символы), 1С перестает распознавать статус записи.
Коллизии внутренних идентификаторов (ID): В распределенных базах (УРБД) документы могут получить одинаковые внутренние ID (Internal ID), что вводит систему в ступор при попытке построения дерева ссылок.
Лимит размера файла 2 ГБ: Для формата DBF это критический порог. При приближении к нему запись в таблицы (например, в 1SBLOB.dbf, где хранятся комментарии и длинные строки) начинает происходить с ошибками.

Шаг 1: Предварительная диагностика и проверка индексов

Перед тем как приступать к серьезным манипуляциям, выполним базовые действия. Проверим, видны ли пометки визуально в журналах. Если «крестики» на документах есть, но поиск ссылок через контекстное меню документа не дает результатов, значит, проблема в целостности таблиц.

Попробуем выполнить полную переиндексацию. Для этого необходимо:

Завершить работу всех пользователей.
Удалить все файлы с расширением .CDX из каталога базы данных.
Запустить 1С в монопольном режиме — система автоматически предложит переиндексировать данные.

Если после этого документы всё еще не появились в списке на удаление, переходим к более глубокому анализу.

Шаг 2: Тестирование и исправление (ТиИ) на копии базы

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

При запуске ТиИ в конфигураторе (Администрирование — Тестирование и исправление данных) рекомендуется установить следующие флаги:

Проверка целостности данных.
Проверка ссылочной целостности.
Пересчет итогов.
Упаковка таблиц (это физически удалит записи, помеченные как удаленные в DBF, и очистит «мусор»).

Рассмотрим пример реального лога после выполнения ТиИ при подобных симптомах:


1SJOURN - 1246850. Неверный признак удаленности записи -  
1SJOURN - 1246851. Неверный признак удаленности записи - .
1SJOURN - 1246852. Неверный признак удаленности записи - ,
Файл 1SBLOB.dbf. Запись 733982. Поле BLOCK. Неверное содержимое текстового поля...
Проверка таблиц документов. Документ ПеремещениеТМЦ. Нет в журнале документов. Удалено.
Проверка уникальности внутреннего идентификатора. Исправить вручную.

Проанализируем эти ошибки. Сообщение «Неверный признак удаленности записи» в файле 1SJOURN прямо указывает на то, почему документы не попадали в список удаления. Система не могла корректно прочитать статус записи из-за битых байтов. ТиИ исправляет эти записи, возвращая им валидное состояние или очищая их.

Шаг 3: Программное удаление как альтернатива

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

Рассмотрим пример кода внешней обработки, которая поможет выявить проблемные ссылки:


// Создаем список объектов для удаления
СписокДокументов = СоздатьОбъект("СписокЗначений");
Док = СоздатьОбъект("Документ.Реализация");
Док.ВыбратьДокументы(ДатаНач, ДатаКон);
Пока Док.ПолучитьДокумент() = 1 Цикл
    Если Док.ПометкаУдаления() = 1 Тогда
        СписокДокументов.ДобавитьЗначение(Док.ТекущийДокумент());
    КонецЕсли;
КонецЦикла;

// Вызываем метод удаления
ТаблицаСсылок = СоздатьОбъект("ТаблицаЗначений");
УдалитьОбъекты(СписокДокументов, 1, ТаблицаСсылок);

// Если есть ссылки, препятствующие удалению, они попадут в ТаблицуСсылок
Если ТаблицаСсылок.КоличествоСтрок() > 0 Тогда
    ТаблицаСсылок.ВыбратьСтроку();
КонецЕсли;

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

Шаг 4: Работа с критическими ошибками (ID и 2 ГБ)

Если в логе ТиИ вы видите сообщения о неуникальности внутреннего идентификатора, это серьезная проблема для УРБД. Это означает, что два физически разных документа имеют один и тот же Internal ID. В таком случае удаление одного может привести к непредсказуемым последствиям для другого.

В такой ситуации рекомендуется:

Выяснить префиксы баз в УРБД.
Найти дублирующиеся записи через прямые запросы или специализированные утилиты для работы с DBF.
Если база приближается к 2 ГБ, необходимо срочно выполнить свертку базы данных или переход на версию SQL. В формате DBF файлы 1SJOURN и 1SBLOB являются самыми уязвимыми.

Радикальное решение: Выгрузка и загрузка данных

Если Тестирование и исправление не помогает или ошибок слишком много, применим «золотой стандарт» восстановления 1С 7.7 — полную выгрузку данных в формат .zip и загрузку в пустую структуру.

Разберем, почему это эффективно: При выгрузке (Конфигуратор — Администрирование — Выгрузка данных) система считывает только логически верные записи. При последующей загрузке (Загрузка данных) все таблицы .DBF и файлы индексов .CDX пересоздаются с нуля. Это полностью устраняет физический мусор, исправляет «битые» признаки удаленности и очищает базу от призраков документов, которых нет в журнале, но которые остались в таблицах DH*.

Резюмируем: при возникновении проблем с удалением в 1С 7.7 последовательно проходим путь от переиндексации до ТиИ. Если лог ТиИ показывает ошибки в 1SJOURN, значит, мы на верном пути. После исправления признаков удаленности и упаковки таблиц документы снова станут доступны для стандартных механизмов очистки базы.