Почему в 1С 7.7 не открывается форма документа и как исправить ошибку «Запись заблокирована»?

← На главную

В практике сопровождения баз 1С:Предприятие 7.7 (особенно на платформе MS SQL Server) встречается критическая ситуация: при попытке открыть конкретный документ программа аварийно закрывается либо ничего не происходит, а при повторной попытке интерактивного открытия появляется системное предупреждение «Запись заблокирована». При этом точка останова в процедуре ПриОткрытии() модуля формы не срабатывает, встроенный отладчик вообще не перехватывает управление, а типовое «Тестирование и исправление ИБ» не выявляет проблем.

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

Причины сбоя и механизм зависания блокировки

Проанализируем механику работы платформы 1С 7.7 при открытии формы объекта:

Блокировка записи: В момент интерактивного открытия платформа отправляет запрос к базе данных и пытается заблокировать выбранный документ в таблице журнала _1SJOURN и соответствующей таблице шапки DH*.
Инициализация интерфейса (Data Binding): До того как будет выполнен код модуля формы (и даже до вызова предопределенной процедуры ПриОткрытии()), ядро платформы выполняет связывание реквизитов документа с элементами управления диалога (MFC/OLE-контролами).
Критический сбой отрисовки: Если в таблице шапки DH* хранятся некорректные бинарные данные, нарушена длина строк, присутствуют непредусмотренные нулевые символы или содержатся ссылки с недействительными идентификаторами типов (например, после восстановления файла метаданных 1cv7.md или правки ID объектов сторонними утилитами), механизм связывания вызывает системное исключение Access Violation.
Зависание блокировки: Поскольку падение происходит до полной инициализации формы, деструктор окна не вызывается штатно. Клиентская сессия удерживает блокировку строки, и при следующей попытке открыть этот же документ система выдает сообщение «Запись заблокирована».

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

Диагностика структуры метаданных и таблиц базы

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

Разберем по шагам порядок диагностики:

Проверка соответствия идентификаторов журнала и видов документов: Выясним, совпадает ли IDDOCDEF документа в таблице общего журнала _1SJOURN со значением в словаре базы данных 1cv7.dds.
```
-- Проверка идентификаторов документов в журнале
SELECT IDDOC, IDDOCDEF, DATE_TIME_IDDOC, DOCNO 
FROM _1SJOURN 
WHERE IDDOC = ' 7GML1  ';
```
Сравнение с чистой тестовой базой: Создадим пустую базу на основе текущего файла 1cv7.md, создадим один тестовый документ проблемного вида и сверим значения колонок IDJOURNAL и IDDOCDEF с рабочей базой.
Сверка состава полей таблицы шапки (DH): В словаре 1cv7.dds найдем описание таблицы шапки проблемного документа (например, DH1234) и сравним типы и имена колонок SP* с фактической структурой таблицы на сервере SQL. Особенное внимание обратим на поля составного (неопределенного) типа, для которых формируются дополнительные служебные колонки (SP*_TYPE, SP*_RTYPE).

Способы решения проблемы

Рассмотрим практические методы восстановления открытия документов в зависимости от характера повреждения данных.

Метод 1. Поколоночный поиск и зануление битых реквизитов через SQL

Если форма падает из-за некорректного значения в одном из реквизитов шапки, локализуем сбойное поле на копии базы данных. Для этого последовательно очищаем подозрительные колонки в таблице шапки DH<ID> для проблемного IDDOC:


-- Пример поочередного сброса реквизитов шапки для поиска виновника
-- Очистка строковых реквизитов:
UPDATE DH1234 
SET SP1235 = '' 
WHERE IDDOC = ' 7GML1  ';

-- Очистка ссылочных реквизитов (значение пустой ссылки):
UPDATE DH1234 
SET SP1236 = '     0   ' 
WHERE IDDOC = ' 7GML1  ';

-- Очистка числовых реквизитов:
UPDATE DH1234 
SET SP1237 = 0 
WHERE IDDOC = ' 7GML1  ';

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

Метод 2. Программное пересоздание записи шапки через 1С

Если чтение реквизитов через встроенный язык работает штатно, а ручное исправление SQL-запросами затруднено, восстановим документ программно:

Считываем значения всех реквизитов шапки и строк табличной части проблемного документа во временные структуры (через внешнюю обработку).
Напрямую через SQL удаляем поврежденную строку из таблицы шапки DH* для конкретного IDDOC: DELETE FROM DH1234 WHERE IDDOC = ' 7GML1 ';
В сеансе 1С открываем документ в коде обработки, присваиваем реквизитам корректные значения и вызываем метод Записать() (при необходимости временно отключив проведение в модуле документа). Платформа сформирует в таблице DH* абсолютно чистую и валидную структуру записи.

Посмотрим на пример обработки для переноса данных проблемного документа в новый экземпляр:


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

Метод 3. Принудительная реструктуризация таблиц документа

Если проблема носит массовый характер для определенного вида документов после ручной правки метаданных:

Открываем конфигурацию в режиме Конфигуратор монопольно.
В свойствах проблемного документа добавляем временный реквизит шапки (например, ВременныйРеквизит с типом Число).
Сохраняем конфигурацию, инициируя полную перестройку таблицы DH* на уровне базы данных.
После успешного сохранения снова заходим в конфигуратор, удаляем временный реквизит и повторно сохраняем конфигурацию.

Такая процедура заставляет платформу пересоздать SQL-структуру таблицы и корректно инициализировать все системные смещения данных в соответствии с текущим файлом 1cv7.md.