Как проверить наличие монопольного режима 1С 7.7 в bat-файле перед запуском базы

Программист 1С v7.7 IT и автоматизация бизнеса
← На главную

В процессе автоматизации работы с 1С:Предприятие 7.7 системные администраторы и программисты часто сталкиваются с проблемой: если база данных открыта кем-то в монопольном режиме, запуск регламентного задания (например, выгрузки данных или индексации) через планировщик задач приводит к зависанию информационного окна с сообщением «База занята». Это блокирует выполнение скрипта до тех пор, пока оператор не нажмет кнопку «ОК» вручную. Разберем, как программно определить состояние базы и избежать подобных ситуаций.

Метод 1: Анализ временного файла links.tmp

В SQL-версиях 1С 7.7 в каталоге базы данных (в подпапке SYSLOG) создается файл links.tmp, который содержит информацию о текущих подключениях. Проанализируем содержимое этого файла с помощью стандартных средств командной строки Windows. Если в файле присутствует флаг IsMono,Y, значит, кто-то занял базу эксклюзивно.

Рассмотрим вариант реализации на чистом Batch:


@echo off
set db_path=D:\bd\syslog\links.tmp
findstr "IsMono","Y" "%db_path%" && (
    echo База открыта монопольно. Запуск отменен.
    exit /b 1
) || (
    echo База свободна для обычного подключения.
    start "" "C:\Program Files\1Cv77\bin\1cv7.exe" enterprise /d"D:\bd\"
)

Важно помнить, что файл links.tmp может не всегда оперативно обновляться при аварийном завершении работы системы. Однако для большинства штатных ситуаций этот метод является самым простым и не требует стороннего софта.

Метод 2: Использование специализированных утилит (1cusrmon.exe)

Существует проверенная временем консольная утилита 1cusrmon.exe, предназначенная специально для мониторинга пользователей 1С 7.7. Она позволяет получить errorlevel, на основе которого батник может принять решение о дальнейшем действии.

Проанализируем параметры командной строки этой утилиты:

Пример использования в скрипте:


1cusrmon.exe -E1 "D:\1C_Base\"
if errorlevel 1 (
    echo Монопольный режим обнаружен!
    pause
    exit
)
echo База доступна. Запускаем...

Этот способ считается наиболее надежным, так как утилита обращается к механизмам блокировок самой платформы, а не просто парсит текст логов.

Метод 3: Проверка блокировок через VBScript и WinAPI

Если использование внешних .exe файлов запрещено политикой безопасности, мы можем реализовать проверку через VBScript. Логика заключается в попытке захватить файл 1Cv7.LCK. Если файл заблокирован другим процессом, 1С работает. Если же мы пытаемся проверить именно монопольный режим, нужно анализировать смещения байтов в .LCK файле, так как 1С 7.7 резервирует определенные байты для каждого подключения.

Рассмотрим упрощенный пример скрипта, который пытается открыть файл блокировок в эксклюзивном режиме:


Dim fso, folder, lckFile
Set fso = CreateObject("Scripting.FileSystemObject")
lckFile = "D:\1C_Base\1Cv7.LCK"

On Error Resume Next
' Попытка открыть файл для чтения/записи без общего доступа
Set file = fso.OpenTextFile(lckFile, 8, False)

If Err.Number <> 0 Then
    WScript.Echo "Файл заблокирован. Возможно, установлен монопольный режим."
    WScript.Quit 1
Else
    file.Close
    WScript.Echo "База свободна."
    WScript.Quit 0
End If

Сложность этого метода в 1С 7.7 заключается в том, что даже при обычном (разделенном) доступе файл 1Cv7.LCK существует. Для точного определения монопольного режима программисты часто используют библиотеку dynwrapper.dll, чтобы вызвать LockFile из kernel32.dll и проверить конкретные диапазоны байт (смещение около 2 000 000).

Метод 4: Прямой запрос к MS SQL Server

Для SQL-версий наиболее точным индикатором будет состояние сессий на самом сервере БД. Мы можем выполнить запрос через sqlcmd, чтобы проверить наличие блокировок всей базы (DB Exclusive Lock).

Выясним причину через системные таблицы SQL Server:


sqlcmd -S SERVER_NAME -d master -Q "IF EXISTS (SELECT * FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID('Имя_Вашей_Базы') AND request_mode = 'X') SELECT 'Locked' ELSE SELECT 'Free'"

Если запрос возвращает Locked, это означает, что база находится в процессе обслуживания или кто-то зашел монопольно. Это исключает ошибки, связанные с «зависшими» файлами links.tmp на сетевых шарах.

Метод 5: Метод «Семафора» для регламентных заданий

Проанализируем ситуацию, когда у нас есть несколько разных регламентов, которые не должны пересекаться. Вместо того чтобы полагаться на механизмы 1С, мы можем создать систему флаг-файлов.

Алгоритм работы:

  1. Первый батник перед запуском 1С создает файл task1.busy.
  2. Второй батник перед стартом проверяет: if exist task1.busy exit.
  3. По завершении работы 1С первый батник удаляет свой флаг-файл.

Этот подход не проверяет наличие живых пользователей, но гарантирует, что ваши собственные скрипты (например, архивация и переиндексация) не столкнутся друг с другом.

Рекомендации по автоматизации

Подводя итог, можно сказать: если вы работаете с SQL-версией, лучше всего комбинировать проверку links.tmp с запросом к SQL-серверу. Если база файловая — использование 1cusrmon.exe или скрипта на VBS с проверкой доступа к 1Cv7.LCK будет оптимальным решением. Это позволит избежать появления модальных окон «База занята» и обеспечит бесперебойную работу ночных регламентов.

← На главную