Ситуация, когда из-за неосторожных действий в SQL-консоли или сбоя индексов «улетает» таблица журнала документов, кажется катастрофической. Однако в архитектуре 1С:Предприятие 8.3 журналы документов являются избыточными структурами. Это означает, что сами данные (документы) хранятся в своих отдельных таблицах, а журнал лишь агрегирует информацию из них для быстрого отображения в списках. Разберем подробно, как вернуть данные в журнал, не прибегая к полному перепроведению документов и не рискуя целостностью базы.
Прежде чем приступать к восстановлению, проанализируем ситуацию. Таблицы журналов в SQL обычно имеют префикс _DocumentJournalXXXX. Если вы случайно выполнили команду DELETE или DROP TABLE для такой таблицы, пользователи увидят пустой список в интерфейсе программы, хотя сами документы (например, «Реализация товаров и услуг» или «Кассовое поступление») будут доступны по прямым ссылкам или через свои отдельные списки. Наша задача — заставить систему заново заполнить эту агрегирующую таблицу на основе существующих данных документов.
Это самый надежный и официальный метод, рекомендованный платформой. Рассмотрим его по шагам:
Проанализируем, что произойдет: платформа сверит описание метаданных с физическими таблицами в SQL. Обнаружив отсутствие или пустоту таблицы журнала, 1С инициирует её пересоздание и автоматическое заполнение всеми документами, которые входят в состав этого журнала. Минус этого способа — длительное время выполнения на больших базах, так как реструктуризация затронет все таблицы.
Если база огромная и мы не хотим ждать полного ТиИ, мы можем заставить систему пересоздать только нужный нам журнал. Разберем, как это сделать:
Комментарий в свойствах объекта или слегка изменим Синоним).Система увидит изменения в метаданных конкретного объекта и выполнит реструктуризацию только таблицы _DocumentJournalXXXX. Это гораздо быстрее и эффективнее в условиях ограниченного времени.
Рассмотрим вариант, когда мы хотим восстановить записи программно, не меняя структуру метаданных. Мы можем использовать свойство ОбменДанными.Загрузка = Истина. Это критически важный момент: данный флаг позволяет записать документ без срабатывания бизнес-логики (подписок на события, проведения по регистрам), но при этом запись в таблицу журнала будет создана или обновлена автоматически.
Пример кода для восстановления записей в журнале:
Выборка = Документы.РеализацияТоваровУслуг.Выбрать(ДатаНачала, ДатаКонца);
Пока Выборка.Следующий() Цикл
Объект = Выборка.ПолучитьОбъект();
Объект.ОбменДанными.Загрузка = Истина;
Объект.Записать(РежимЗаписиДокумента.Запись);
КонецЦикла;
Проанализируем этот код: мы просто перебираем документы и переписываем их поверх самих себя. Благодаря режиму Загрузка = Истина, 1С не будет пытаться заново делать движения по регистрам, проверять остатки или менять состояние документа. Платформа просто «освежит» запись в базе данных, что автоматически добавит строку в таблицу журнала.
Если у вас есть копия базы (пусть и устаревшая на пару дней), можно попробовать восстановить часть данных напрямую через SQL Server Management Studio. Посмотрим на алгоритм:
INSERT INTO ... SELECT ... перенесем данные из таблицы журнала архивной базы в основную.Важно: При ручных операциях с SQL-таблицами журналов нужно быть крайне осторожными с полями _DocumentTRef (идентификатор типа) и _IDRRef (ссылка на документ). Если вы не уверены в структуре этих полей, лучше использовать методы через Конфигуратор 1С.
Выясним причину, почему реструктуризация является приоритетным методом. Она гарантирует, что внутренние идентификаторы (UUID) объектов не изменятся, а связи с правами доступа и другими объектами системы останутся корректными. Попытки удалить журнал из дерева конфигурации и создать его заново (как предлагалось в некоторых сообщениях форума) чреваты потерей ссылок в отчетах и ролях пользователей.
В будущем, чтобы избежать подобных инцидентов, рекомендуем:
SELECT для проверки выборки перед тем, как нажать DELETE.