Каждый системный администратор и программист 1С рано или поздно сталкивается с ситуацией, когда классическое обслуживание базы данных приводит к неожиданным и катастрофическим результатам. Представьте картину: вы переносите базу данных 1С 7.7 (в формате DBF) на новый сервер, запускаете штатную переиндексацию и встроенную проверку в режиме «Только тестирование» (без исправления!). Все завершается успешно, но на следующий день бухгалтерия в панике сообщает, что Оборотно-сальдовая ведомость (ОСВ) «поплыла», а управленческий баланс не сходится на миллионы.
В этой статье мы подробно разберем, почему штатные механизмы платформы 1С 7.7 в режиме чтения способны физически изменить данные на диске, как некорректная «свертка» базы в прошлом закладывает скрытую бомбу замедленного действия и какие шаги необходимо предпринять, чтобы избежать потери данных при обслуживании старых систем.
---
Для того чтобы понять физику процесса, нам необходимо заглянуть внутрь файловой СУБД 1С 7.7. База данных состоит из набора таблиц с расширением .DBF и соответствующих им индексных файлов с расширением .CDX. Ниже приведены ключевые файлы таблиц, которые участвуют в формировании бухгалтерских и оперативных результатов:
1SJOURN.DBF — общий журнал документов. Здесь хранятся заголовки всех документов (дата, номер, вид документа, пометка удаления, статус проведения).1SENTRY.DBF — таблица проводок. Именно здесь физически записаны все бухгалтерские проводки (дебет, кредит, субконто, сумма).1SBKTTL.DBF — таблица остатков и оборотов (бухгалтерские итоги). Здесь хранятся предварительно рассчитанные итоги по счетам и субконто по кварталам.RG*.DBF и RA*.DBF — таблицы итогов и движений регистров накопления (для оперативного учета).При формировании стандартных отчетов (например, ОСВ) система 1С 7.7 из соображений быстродействия не сканирует всю таблицу проводок 1SENTRY.DBF с самого начала ведения учета. Вместо этого платформа обращается к уже готовым, предрассчитанным итогам в таблице 1SBKTTL.DBF на начало нужного периода и быстро прибавляет к ним обороты. Это ключевой момент для понимания природы описываемой проблемы.
---
Проанализируем классическую ошибку, которую часто совершали приглашенные специалисты или франчайзи при «облегчении» тяжелых баз. Когда объем базы 1С 7.7 приближался к критическому, базу решали «урезать» за прошлые года (например, удалить данные за 2004–2005 гг.).
Если «свертка» выполнялась непрофессионально (например, простым удалением записей из таблицы документов или грубыми обработками очистки журнала 1SJOURN.DBF), происходило следующее:
1SJOURN.DBF физически удалялись или помечались на удаление.1SENTRY.DBF и движения регистров в RA*.DBF оставались нетронутыми («сиротские проводки»).1SBKTTL.DBF и RG*.DBF продолжали хранить старые остатки, которые когда-то были сформированы этими удаленными документами.В результате база данных переходила в состояние «мнимого благополучия». Бухгалтеры открывали базу, строили отчеты и видели красивые, правильные цифры, потому что отчеты читали предрассчитанные итоги. Но под этими цифрами на самом деле уже не было фундамента — первичных документов-основателей.
---
В официальной документации 1С утверждается, что режим «Только тестирование» открывает файлы базы исключительно в режиме чтения. Однако это правило не распространяется на операцию «Пересчет итогов».
Физически невозможно произвести пересчет бухгалтерских или оперативных итогов «виртуально» в оперативной памяти компьютера. Когда вы запускаете проверку и отмечаете флажок «Пересчет итогов», платформа выполняет следующие принудительные дисковые операции:
1SBKTTL.DBF и регистров накопления RG*.DBF.1SENTRY.DBF и движения из RA*.DBF, собирая баланс заново с первого исторического документа в базе.Когда алгоритм пересчета доходит до «сиротских проводок» (у которых стерты или повреждены документы-регистраторы в журнале 1SJOURN.DBF), платформа классифицирует их как некорректные. Система либо игнорирует эти суммы, либо связывает их с «пустыми» объектами.
В итоге новые таблицы остатков 1SBKTTL.DBF записываются на диск в «очищенном» виде. Привычные для бухгалтерии «законсервированные» остатки прошлых лет безвозвратно исчезают, а текущие рабочие балансы мгновенно разъезжаются.
---
Выясним еще одну важную техническую деталь. В файловой системе dBASE (DBF) существует жесткое ограничение на максимальный размер одного файла таблицы — 2 Гб. Если общий объем базы составляет 1.7 Гб, то отдельные наиболее активные таблицы (например, проводки или итоги) могут находиться на грани этого лимита.
Когда размер таблицы приближается к 2 Гб, запись новых данных блокируется СУБД, а индексные файлы *.CDX начинают систематически разрушаться. Именно по этой причине на старом сервере у пользователей ежедневно зависала процедура переиндексации.
При переносе базы на новый сервер и первом запуске платформы в монопольном режиме система принудительно восстанавливает разрушенные индексы. Новая переиндексация на физически поврежденной СУБД может отбросить некорректные или недописанные транзакции, что также приводит к резкому изменению результатов отчетов сразу после запуска базы.
---
Для того чтобы доказать руководству или обслуживающему франчайзи наличие логических разрушений в базе данных до проведения ваших работ, можно запустить несложную обработку. Напишем пример кода для 1С 7.7, который сканирует проводки и находит записи, потерявшие связь с документами журнала:
// Создаем объект для работы с бухгалтерскими операциями
Операция = СоздатьОбъект("Операция");
Операция.ВыбратьОперации();
КоличествоСирот = 0;
Пока Операция.ПолучитьОперацию() = 1 Цикл
// Проверяем связь операции с документом
Док = Операция.Документ;
Если Док.Выбран() = 0 Тогда
КоличествоСирот = КоличествоСирот + 1;
Сообщить("Найдена проводка без документа! Номер операции: " + Операция.НомерДок + " от " + Операция.ДатаДок);
КонецЕсли;
КонецЦикла;
Если КоличествоСирот > 0 Тогда
Предупреждение("Внимание! В базе обнаружено логическое разрушение. Количество поврежденных проводок: " + КоличествоСирот);
Иначе
Сообщить("Связи документов и проводок в порядке.");
КонецЕсли;
---
Для предотвращения подобных инцидентов разработаем строгую последовательность действий при работе с любыми унаследованными (legacy) базами данных.
.XLS) или .MXL. Вы должны иметь жесткие ориентиры для сверки «до» и «после».Рассмотренный случай наглядно доказывает: даже если вы пришли «просто помочь» и запустили штатную безвредную функцию платформы, в глазах заказчика виновным в крахе базы окажется тот, кто последним нажал кнопку в Конфигураторе. Будьте бдительны и всегда подстраховывайте себя созданием независимых архивных копий.