Добрый день. внезапно у нового клиента, для которого в копию их базы была сделана интеграция, выяснилось, что их реальная рабочая база тоже файловая. Я раньше представлял так, что если база файловая, то фоновые задания в ней работают пока в ней есть хотя-бы один пользователь в онлайне. Но тест на копии их базы показал, что статистика звонков сливается с астериска только при постоянном нажатии кнопки Получить Пакет Истории в разделе расписание. Можно ли как-то организовать выполнение фонового задания закачки звонков в файловой базе?
--- С Уважением, Казанджиян Александр ООО "Ика Телеком" Официальный партнёр компании МИКО +7(916)9995522 +7(495)7822119 7822119@gmail.com www: http://1c.sipbox.ru/
Петр Петр Русланов написал: Я раньше представлял так, что если база файловая, то фоновые задания в ней работают пока в ней есть хотя-бы один пользователь в онлайне.
На сколько мне известно, это справедливо для конфигураций на базе БСП. Режим запуска "Управляемое приложение". Мы не рекомендуем работу в файловом варианте. Этот вариант не может работать быстро при многопользовательской работе. Есть ограничения на размеры файла базы данных.
Я всё понимаю про ограничения и знаю, что Вы рекомендуете клиент-серверный вариант. Однако вопрос остался открытым. Возможно ли заставить работать расписание, чтобы данные о звонках всё таки скачивались автоматически, а не только по нажатию кнопки Получить... ?
Если автоматический запуск заданий не поддерживается в вашей конфигурации: Поручите программисту реализовать мехнизм используйте метод платформы "ПодключитьОбработчикОжидания".
// ИКА Телеком. процедура вызывает загрузку звонков из АТС Процедура ВызываемЗакачкуЗвонков() экспорт МИКО_стСлужебный.реглПолучитьПакетИсторииСAsterisk(); КонецПроцедуры
Работает уже несколько дней. То есть получается, что в сессии каждого пользователя происходит вызов закачки. Но сегодня что то база начала уходить в раздумья у всех пользователей. При этом я сразу стал подозревать этот самый наш "запил". В журнале регистрации видно, что вызов этой процедуры происходит чуть ли не каждые 10-20 сек А иногда в журнале встречается такое:
CDR: {ОбщийМодуль.МИКО_стЗагрузкаИсторииЗвонков_v7.Модуль}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу '_InfoRg9461': Не удалось заблокировать таблицу '_InfoRg9461'
и такое:
CEL: {ОбщийМодуль.МИКО_стЗагрузкаИсторииЗвонков_v7.Модуль}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Не удалось заблокировать таблицу '_InfoRg9497': Не удалось заблокировать таблицу '_InfoRg9497'
Возможно именно в эти моменты 1С уходил в песочные часы секунд на 20. Подозреваю, что слишком одновременно в нескольких сессиях происходил вызов процедуры.
В базе работают пока около 5-7 человек. Есть идеи, как избежать таких проблем? Думаю таймаут подписки на обработчик ожидания увеличить с 120 до 600 сек. И еще добавлять к нему рандомную величину (от +120с до -120с).
Что скажете?
--- С Уважением, Казанджиян Александр ООО "Ика Телеком" Официальный партнёр компании МИКО +7(916)9995522 +7(495)7822119 7822119@gmail.com www: http://1c.sipbox.ru/
Синхронизация должна работать только в одном сеансе из множества. Вам попросту может не хватить лицензий на модуль. Лицензия будет привязана к определенному хост (пк), то есть нужно выбрать ПК сервер и запустить на нем сеанс 1С. Только с этого ПК должна выполняться синхронизация.
Ну на лицензию модуль не ругается, наверное потому, что все сидят на одном терминальном сервере. Я сделал интервал синхронизации 5 минут + случайная величина от 1 сек до 60 сек. То есть у каждого пользователя будет свой интервал проверок.
Сегодня всё работает, но странно, что в утренние часы с до 12 часов снова в журнале есть конфликты блокировок, но потом заканчиваются и не возникают