← На главную
В процессе многопользовательской работы в типовой конфигурации 1С:Бухгалтерия предприятия 3.0 в файловом режиме (файл 1Cv8.1CD) пользователи нередко сталкиваются с системной ошибкой: «Конфликт блокировок при выполнении транзакции» с указанием на строку модуля {ОбщийМодуль.ОбработкаНовостей.Модуль}: Ошибка при вызове метода контекста (Записать) Запись.Записать(Истина). Параллельно с этим при попытке сохранения или проведения любых первичных документов может возникать сопутствующая ошибка: «В данной транзакции уже происходили ошибки», после чего документ закрывается несохраненным.
Разберем детально архитектурные причины этой проблемы в файловом режиме и пошагово рассмотрим методы её гарантированного устранения.
Почему возникает конфликт блокировок и ошибка транзакции
Проанализируем техническую сторону работы файловых баз данных 1С:
- Табличные блокировки файлового формата
.1CD: В отличие от клиент-серверного варианта (SQL), где работают тонкие управляемые блокировки на уровне отдельных строк, файловая СУБД 1С при записи объекта блокирует физическую таблицу целиком. Если один сеанс выполняет запись в служебный регистр сведений (например, КатегорииНовостейИнтервалыВерсий или Новости), остальные сеансы встают в очередь ожидания.
- Эмуляция фоновых заданий в сеансах пользователей: В файловом режиме отсутствует отдельный серверный процесс для выполнения регламентных процедур. Фоновые задачи (автоматическое получение новостей, обновление классификаторов) неявно запускаются прямо внутри клиентских приложений работающих пользователей. При одновременном запуске нескольких сеансов возникает острая конкуренция за общие служебные таблицы.
- Механизм отката транзакции: Когда бухгалтер проводит документ, платформа открывает явную транзакцию. Если в этот же момент фоновый поток или подписка на события пытается обратиться к заблокированной таблице новостей и ловит таймаут, вся родительская транзакция помечается платформой как ошибочная. Последующая попытка зафиксировать транзакцию закономерно вызывает исключение «В данной транзакции уже происходили ошибки», приводя к отмене записи документа.
- Блокировка таблицы
_SCHEDULEDJOB: При попытке выключить регламентное задание в тот момент, когда другой сеанс уже опрашивает планировщик, возникает сбой блокировки таблицы служебных заданий _SCHEDULEDJOB.
Шаг 1. Отключение автоматической загрузки новостей в монопольном режиме
Для того чтобы избежать ошибки не удалось заблокировать таблицу _SCHEDULEDJOB, все операции по изменению расписания и отключению регламентных процедур необходимо выполнять в монопольном режиме.
- Попросим всех пользователей временно завершить работу с программой 1С.
- Убедимся в отсутствии активных или зависших сеансов: откроем меню Администрирование → Обслуживание → Активные пользователи. При необходимости завершим оставшиеся сеансы.
- Перейдем в раздел Администрирование → Интернет-поддержка и сервисы → Новости (или Настройки новостей) и снимем флаги автоматического получения и отображения новостей.
- Перейдем в раздел Администрирование → Обслуживание → Регламентные и фоновые задания.
- Найдем на вкладке Регламентные задания все процессы, связанные с новостной лентой:
Обновление новостей и Загрузка новостей.
- Откроем каждое из них, снимем признак Включено и нажмем кнопку Записать и закрыть.
Шаг 2. Корректировка времени ожидания блокировок
Рассмотрим способ снижения чувствительности платформы к кратковременным коллизиям при записи данных. Если системный таймаут слишком мал, платформа быстро прерывает транзакцию ошибкой, не дождавшись освобождения таблицы соседним сеансом.
- Откроем информационную базу в режиме Конфигуратор в монопольном режиме.
- Перейдем в главное меню: Администрирование → Параметры информационной базы...
- Найдем параметр Время ожидания блокировки данных (по умолчанию установлено 20 секунд).
- Увеличим значение параметра до
40 или 60 секунд и нажмем ОК. Это позволит сеансам дольше ожидать завершения параллельных дисковых операций без аварийного сброса транзакций.
Шаг 3. Очистка кэша и проверка целостности базы данных
Нередко причиной постоянных взаимоблокировок служебных таблиц становится поврежденный локальный кэш конфигурации на рабочих станциях или логические ошибки в структуре файла базы.
- Очистка пользовательского кэша: Завершим работу 1С на компьютерах пользователей и удалим содержимое временных служебных каталогов с GUID-именами по путям:
%AppData%\1C\1Cv8\
%LocalAppData%\1C\1Cv8\
- Физическая проверка утилитой chdbfl: Создадим резервную копию файла
1Cv8.1CD. Запустим утилиту chdbfl.exe (находится в каталоге bin установленной платформы 1С), выберем файл базы, установим флаг Исправлять обнаруженные ошибки и выполним проверку.
- Тестирование и исправление: Запустим Конфигуратор, перейдем в меню Администрирование → Тестирование и исправление..., выберем режимы Реиндексация таблиц информационной базы, Проверка логической целостности и Пересчет итогов, после чего запустим процесс восстановления.
Шаг 4. Радикальное устранение проблемы блокировок файлового режима
Если в базе одновременно работают от 3 до 5 и более человек, файловый доступ по локальной сети (через общий сетевой ресурс SMB) неизбежно будет приводить к падению производительности и коллизиям блокировок при записи любых учетных документов. Рассмотрим два варианта архитектурного решения:
- Публикация файловой базы на веб-сервере (Apache / IIS): База данных публикуется на локальном веб-сервере. Пользователи подключаются через тонкий клиент по протоколу HTTP/HTTPS. В этом случае монопольную работу с файлом
.1CD ведет один системный процесс веб-сервера, что исключает сетевые блокировки файловой системы Windows и некорректное поведение регламентных заданий.
- Переход на клиент-серверный режим (SQL): Использование сервера 1С:Предприятие и реляционной СУБД (PostgreSQL, Microsoft SQL Server). В клиент-серверной архитектуре все регламентные задачи выполняются изолированно на сервере, а транзакции блокируют только конкретные изменяемые строки таблиц с помощью управляемых блокировок, полностью исключая конфликты при проведении документов.