привествую! есть ли способ "перехватить" сообщение, которое вываливается пользователю при запуске 1С, в случае если база уже запущена в монопольном режиме?
Хочется формировать это сообщение самому... напимер писать в него пользователя, который "занял" базу монопольно, + еще кое-какую инфу, которая хранится в БАЗЕ!
Это вообще возможно?
Хочется формировать это сообщение самому... напимер писать в него пользователя, который "занял" базу монопольно, + еще кое-какую инфу, которая хранится в БАЗЕ!
Это вообще возможно?
По теме из базы знаний
- DBEng32 (8.0.1.2, Share) – выполнение прямых запросов и в монопольном режиме для DBFной версии 1С:Предприятие 7.7 в среде 1С++
- Приемы обработки больших данных в 1С
- Отправка электронной почты с помощью локального почтового клиента из 1С, развернутой под удаленным рабочим столом
- Многопоточное обновление 1С: Управление холдингом
- Пример подключения локальных моделей ИИ (нейросетей, LLM) в конфигурацию 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Хочется формировать это сообщение самому
Средствами языка 1С это невозможно: сообщение формируется платформой, надо либо ее патчить, либо писать свою приблуду.
напимер писать в него пользователя, который "занял" базу монопольно
Это еще как-то можно реализовать в своей программе, сэмулировав работу "Монитора пользователей" 1С.
+ еще кое-какую инфу, которая хранится в БАЗЕ!
А вот это - точно фигвам: ОС не допустит никакую программу к файлам базы, открытым монопольно.
(11)
Никаких проблем. Проверено многолетней эксплуатацией. Проверка 1С на монопольный запуск не рушится, это проверяется без обращения к базе данных. Зато начинают без геморроя работать регламентные процедуры SQL, не спотыкаясь на монопольно открытых базах. Вот настраиваешь, например, в SQL план обслуживания, бэкап. Не отдельным планом для каждой базы, а один по списку пользовательских баз. И если кто-то из пользователей оставил монопольно открытую 1С, не будет бэкапа не только по этой базе, но и по всем, которые ниже по списку.
Мерещится мне, что это чревато последствиями куда худшими, чем нерешенность исходной задачи автора ветки.
Никаких проблем. Проверено многолетней эксплуатацией. Проверка 1С на монопольный запуск не рушится, это проверяется без обращения к базе данных. Зато начинают без геморроя работать регламентные процедуры SQL, не спотыкаясь на монопольно открытых базах. Вот настраиваешь, например, в SQL план обслуживания, бэкап. Не отдельным планом для каждой базы, а один по списку пользовательских баз. И если кто-то из пользователей оставил монопольно открытую 1С, не будет бэкапа не только по этой базе, но и по всем, которые ниже по списку.
(1) Вообще, после запуска 1С в каталоге журнала - "База\SYSLOG\" создается или обновляется файл "links.tmp" и там бухвально в открытом виде пишется кто, когда, откуда зашел, монопольно или нет и в каком режима. Можно накидать скрипт на VBS который будет парсить файл и смотерть есть монопольный вход или нет. И в зависимости от этого запускать или нет "1cv7". По поводу чтения инфы из открытых монопольно файлов - реализуемо но с заворотом геморроя (ну т.е. вариант с низкоуровневым чтением никто не отменял, или подобные вещи, типа сделать архив винраром с флагом копирования занятых файлов), если база на SQL то ув. в (10) описал вполне рабочий вариант.
МонопольныйРежим()
Синтаксис:
МонопольныйРежим()
Назначение:
Возвращает значение режима работы программы: 1 - программа запущена в монопольном режиме; 0 - программа запущена в сетевом режиме.
Упс. Вопрос неверно понял. Фигню написал.
Синтаксис:
МонопольныйРежим()
Назначение:
Возвращает значение режима работы программы: 1 - программа запущена в монопольном режиме; 0 - программа запущена в сетевом режиме.
Упс. Вопрос неверно понял. Фигню написал.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот