Каждый специалист 1С рано или поздно сталкивается с ситуацией, которая с первого взгляда кажется чистой мистикой. Представьте картину: вы успешно выполнили доработку печатной формы или конфигурации, проверили её работу, пользователи ввели массив документов, но на следующий день всё это бесследно исчезает. Пропадают и ваши программные изменения, и целые дни работы пользователей. При этом в базе нет штатного программиста-вредителя, а обычные бухгалтеры физически не способны совершить подобное удаление.
В этой статье мы подробно проанализируем, почему файловые базы 1С при работе по локальной сети склонны к подобным «фокусам». Мы детально разберем физику процесса, скрытые механизмы операционной системы Windows и самой платформы 1С:Предприятие, а также выработаем пошаговый план спасения данных.
---
Давайте разберем типичную техническую схему работы небольшой компании. База данных 1С в файловом варианте (файл 1Cv8.1CD) лежит на обычном компьютере одного из сотрудников (который выполняет роль «сервера»), а остальные 6–8 пользователей подключаются к этой папке по локальной сети через общий сетевой ресурс.
В современных операционных системах Windows по умолчанию включены механизмы оптимизации сетевого обмена данными. Самые опасные из них для баз данных — это Opportunistic Locking (Oplocks) и Directory Leasing (в протоколах SMB2 и SMB3).
Как работает этот механизм: чтобы постоянно не гонять тяжелые файлы по сети, операционная система на компьютере пользователя временно кэширует операции записи. Когда пользователь проводит документ, Windows рапортует платформе 1С: «Всё записано!», хотя физически данные еще находятся в оперативной памяти клиентской машины и ждут отправки на «сервер» удобным пакетом.
Почему пропадают данные: если в локальной сети происходит даже микросекундный сбой (моргнул роутер, отошел сетевой кабель, компьютер «задумался»), сетевой сеанс аварийно разрывается. Клиентская операционная система очищает свой неотправленный кэш, а файл базы данных 1Cv8.1CD на сервере откатывается к тому состоянию, в котором он был до начала сессии кэширования. В результате документы за последние несколько часов или даже дней просто испаряются. При этом в Журнале регистрации 1С записей об удалении не будет, так как сам Журнал регистрации записывается в тот же сетевой кэш и откатывается вместе с базой.
---
Проанализируем еще одну встроенную технологию Windows, которая часто включается системными администраторами для «надежности», но уничтожает базы данных 1С.
Служба «Автономные файлы» предназначена для того, чтобы пользователи ноутбуков могли работать с сетевыми файлами даже при отсутствии подключения к сети. Если папка с базой 1С расшарена, Windows может посчитать сетевое соединение нестабильным (например, из-за высокой нагрузки, создаваемой файловой базой 1С) и незаметно переключить пользователя на локальный кэш автономных файлов.
Бухгалтер продолжает работать, вводить документы, проводить операции. Он думает, что работает в общей базе, но на самом деле пишет данные в скрытую локальную копию на своем жестком диске. Вечером связь стабилизируется, и Windows пытается выполнить синхронизацию. В процессе этой автоматической синхронизации локальная копия базы может просто затереть файл на сервере (или серверный файл затрет локальный). Итог — колоссальная потеря данных и полная неразбериха.
---
Каждый программист 1С любит экономить время и обновлять конфигурацию «на лету», когда пользователи работают в системе. В этот момент платформа вносит изменения в конфигурацию базы данных динамически.
В файловом режиме при параллельной работе 7-8 пользователей по сети динамическое обновление — это бомба замедленного действия. Обратите внимание на симптомы из темы: пользователи часто жалуются на блокировку таблицы config. Это верный признак того, что кэш метаданных поврежден.
Как пропадают доработки программиста: при динамическом обновлении новые объекты метаданных записываются во временные таблицы БД. Если в этот момент у кого-то из пользователей зависает сессия или некорректно отрабатывает локальный сетевой кэш, транзакция фиксации изменений зависает. При следующем монопольном запуске Конфигуратора или запуске утилиты тестирования платформа обнаруживает логическую несогласованность данных в таблице config и выполняет автоматический откат конфигурации к последней стабильной контрольной точке. Все ваши новые модули, макеты и печатные формы мгновенно стираются, возвращаясь к исходному состоянию.
---
Нельзя сбрасывать со счетов классическую организационную проблему. Рассмотрим типичный сценарий:
В результате все изменения конфигурации, внесенные программистом в понедельник, и все документы, введенные другими пользователями за этот день, бесследно затираются старым файлом с флешки.
---
Выше было упомянуто, что после запуска «Тестирования и исправления» (ТиИ) с флагом «Создавать объекты» данные пропали строго до границы определенной даты. Давайте проанализируем, почему это происходит.
Если файл 1Cv8.1CD повреждается из-за сетевых сбоев, утилита chdbfl.exe пытается исправить заголовки таблиц и структуру страниц. Если страница с индексами или записями документов (например, за последние 2 дня) повреждена, утилита не восстанавливает эти данные — она их просто удаляет (отрезает), чтобы вернуть базу к работоспособному физическому состоянию.
Когда вы запускаете ТиИ на такой «обрезанной» базе с включенной опцией очистки недействительных ссылок, система находит тысячи записей в регистрах накопления и сведений, которые ссылаются на несуществующие (удаленные утилитой) документы. Платформа очищает эти движения. Визуально это выглядит так, будто документы испарились, хотя на самом деле они были разрушены еще до тестирования, а ТиИ лишь завершило процесс очистки базы от «мусора».
---
Чтобы раз и навсегда избавить клиента от мистической пропажи данных, необходимо выполнить комплекс технических мероприятий. Разберем их по шагам.
На компьютере, выполняющем роль сервера (где физически лежит база данных), необходимо принудительно отключить оптимизацию сетевого кэширования Windows.
Для этого откройте редактор реестра и внесите изменения в параметры службы сервера:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"OplocksDisabled"=dword:00000001
"SharingViolationDelay"=dword:00000000
"SharingViolationRetries"=dword:00000000
После внесения изменений в реестр обязательно перезагрузите компьютер-сервер.
На каждом клиентском компьютере выполните следующие действия:
Возьмите за железное правило: никаких динамических обновлений в файловой базе!
Любые доработки, изменения печатных форм и конфигурации должны вноситься строго в монопольном режиме, когда все пользователи вышли из базы. После каждого обновления конфигурации рекомендуется очищать локальный кэш на рабочих местах пользователей. Сделать это можно, настроив ярлык запуска с параметром /ClearCache, либо запустив простой скрипт очистки каталогов кэша:
@echo off
rmdir /s /q "%userprofile%\AppData\Local\1C\1Cv8"
rmdir /s /q "%userprofile%\AppData\Roaming\1C\1Cv8"
echo Кэш 1С успешно очищен!
pause
Если у клиента нет бюджета на покупку серверной лицензии 1С («клиент-сервер»), а количество активных пользователей составляет 6–8 человек, прямая работа по сети через общую папку гарантированно приведет к новым сбоям.
Решение: настройте публикацию файловой базы на бесплатном веб-сервере (например, Apache или встроенном в Windows IIS).
При такой схеме:
1Cv8.1CD открыт монопольно только одним процессом веб-сервера локально.Чтобы застраховать себя от человеческого фактора (когда базу перезаписывают старой копией с флешки) и контролировать действия пользователей, настройте следующие инструменты:
Проанализировав все эти факторы и внедрив предложенные шаги, мы сможем гарантировать клиенту полную сохранность данных, стабильную работу системы и навсегда забудем о «мистических» исчезновениях документов.