Что делать, если в 1С 7.7 на SQL пропали документы из журнала, хотя таблицы в базе не пусты?

Ситуация, когда при запуске 1С 7.7 пользователи обнаруживают абсолютно пустые журналы документов при физическом наличии данных в SQL-таблицах, является критической и требует глубокого понимания взаимодействия платформы с SQL Server. Рассмотрим причины возникновения этой проблемы и способы её решения, основываясь на практическом опыте системных администраторов.

Разбор архитектурной связи 1С 7.7 и SQL Server

Для начала проанализируем, как 1С 7.7 хранит информацию о документах. Основным связующим звеном является таблица _1SJOURN (общий журнал). В ней хранятся заголовки всех документов системы. Каждая строка этой таблицы содержит поле IDDOCDEF — это идентификатор типа документа, который жестко зашит в файле метаданных 1cv7.md.

Когда вы открываете журнал в интерфейсе "Предприятия", платформа выполняет SQL-запрос к таблице _1SJOURN. Если идентификаторы IDDOCDEF в таблице SQL перестают соответствовать тем, что указаны в текущем MD-файле, 1С просто "не узнает" свои документы и отображает пустой список. Это часто происходит после неудачного обновления конфигурации, сбоев при автоархивации или некорректной работы SQL-сервера.

Проверка целостности данных через SQL-запросы

Прежде чем приступать к манипуляциям с конфигуратором, необходимо выяснить, остались ли данные в самой базе. Разберем, как проверить содержимое таблиц напрямую. Откроем SQL Server Management Studio и выполним следующий запрос:

SELECT TOP 100 * FROM _1SJOURN (NOLOCK)
ORDER BY DATE_TIME_IDDOC DESC

Если запрос возвращает строки с данными, значит, физически документы на месте. Обратим внимание на колонку IDDOCDEF. Нам нужно сопоставить эти значения с тем, что ожидает 1С. Для этого проанализируем файл словаря данных 1cv7.dds, который находится в каталоге базы. В нем можно найти описание таблицы _1SJOURN и список соответствий идентификаторов именам документов.

Причина ошибки «Нарушена структура таблицы 1sjourn»

Выясним причину, по которой при восстановлении из бэкапа система выдает ошибку структуры. Рассмотрим сценарий, когда файлы MD и DDS идентичны, но база не запускается. Это указывает на то, что на уровне SQL Server структура таблицы (количество колонок, их типы или индексы) перестала соответствовать описанию в словаре 1С.

Посмотрим на типичный алгоритм действий, который часто приводит к "невидимости" документов:

1. Администратор вносит фиктивное изменение в конфигурацию (например, добавляет и удаляет пробел в комментарии), чтобы заставить систему пересоздать словарь DDS.
2. При сохранении 1С пытается привести структуру SQL-таблиц к "эталонному" виду из MD.
3. Если в процессе этого "лечения" идентификаторы IDDOCDEF были переназначены или таблица была пересоздана некорректно, документы исчезают из журналов, так как 1С ищет одни ID, а в базе лежат другие.

Метод решения: Восстановление таблицы _1SJOURN

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

Рассмотрим пошагово процесс восстановления:

1. Подготовка копий: Разверните на SQL-сервере две базы из бэкапов (База_Поврежденная и База_Рабочая_Архив).
2. Синхронизация словаря: В поврежденной базе зайдите в конфигуратор, внесите любое несущественное изменение и сохраните конфигурацию. Это создаст корректный файл DDS и позволит базе запуститься, даже если журнал станет пустым.
3. Очистка поврежденной таблицы: В SQL-менеджере выполните команду очистки таблицы общего журнала в поврежденной базе: TRUNCATE TABLE База_Поврежденная.dbo._1SJOURN
4. Перенос данных: Скопируйте данные из "здоровой" таблицы архивной базы в текущую. Это можно сделать через INSERT INTO ... SELECT:
   Скопировать код

   
   INSERT INTO База_Поврежденная.dbo._1SJOURN
   SELECT * FROM База_Рабочая_Архив.dbo._1SJOURN
   

5. Проверка: Запустите 1С:Предприятие. Если идентификаторы совпали, документы мгновенно появятся в журналах.

Важные нюансы работы 1С 7.7 на SQL Server 2008 R2

Проанализируем технический контекст. Платформа 7.7 официально не поддерживает версии SQL выше 2000. Работа на SQL 2008 R2 и выше требует использования специальных библиотек (например, модифицированной BkEnd.dll). Одной из причин "пропадания" документов может быть некорректная работа планировщика SQL Server или скриптов обслуживания.

Рекомендуем обратить внимание на следующие параметры базы в SQL:

• Auto Update Statistics: Иногда автоматическое обновление статистики может блокировать доступ 1С к индексам таблицы _1SJOURN, что возвращает пустой результат запроса.
• Compatibility Level: Убедитесь, что уровень совместимости базы установлен в SQL Server 2000 (80), если это возможно, или тщательно протестируйте поведение на уровне 100.
• DBCC CHECKDB: Регулярно запускайте проверку физической целостности. Пустой журнал при наличии данных часто является признаком повреждения индексов.

Итоги и профилактика

Ситуация, описанная в теме, подтверждает, что при работе с устаревшими платформами на новом системном ПО риск повреждения метаданных крайне высок. Мы выяснили, что "пустой журнал" — это чаще всего проблема несоответствия идентификаторов IDDOCDEF между базой данных и MD-файлом.

Чтобы избежать подобных инцидентов в будущем, рекомендуем всегда хранить архивные копии не только всей базы SQL, но и отдельно файлы 1cv7.md и 1cv7.dds на каждый день. В случае сбоя сравнение файлов DDS утилитами типа fc.exe или WinMerge позволит вам мгновенно увидеть изменения в структуре ID и принять решение о методе восстановления без многочасовых тестов ТиИ (Тестирование и Исправление).