v8.1 Логирование в внешнюю БД #495571

Разрабатываю систему логирования изменений в 1С. Реализован в виде COM-сервера для серверного варианта использования. Всё вроде бы нормально работает, но столкнулся с такой проблемой: локально работает безпроблем, переношу на Win2003 x64 начинает очень нестабильно работать и регулярно уходить в перезагрузку с ошибкой "Тип события:    Ошибка Источник события:    System Error Компьютер:    SRV2 Описание: Код ошибки 000000000000007f, параметр1 0000000000000008, параметр2 0000000080050033, параметр3 00000000000006f8, параметр4 fffffadf880265c7. Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp". Данные: 0000: 53 79 73 74 65 6d 20 45   System E 0008: 72 72 6f 72 20 20 45 72   rror  Er 0010: 72 6f 72 20 63 6f 64 65   ror code 0018: 20 30 30 30 30 30 30 30    0000000 0020: 30 30 30 30 30 30 30 37   00000007 0028: 66 20 20 50 61 72 61 6d   f  Param 0030: 65 74 65 72 73 20 30 30   eters 00 0038: 30 30 30 30 30 30 30 30   00000000 0040: 30 30 30 30 30 38 2c 20   000008, 0048: 30 30 30 30 30 30 30 30   00000000 0050: 38 30 30 35 30 30 33 33   80050033 0058: 2c 20 30 30 30 30 30 30   , 000000 0060: 30 30 30 30 30 30 30 36   00000006 0068: 66 38 2c 20 66 66 66 66   f8, ffff 0070: 66 61 64 66 38 38 30 32   fadf8802 0078: 36 35 63 37               65c7    " Судя по логам COM объект корректно работает, такое ощущение что глючит или сервер 1с под x64 Прилогаю тестовый пак (Отладочная сборка СОМ-сервера, Бланк БД для PGSQL, Тестовая конфа для 8.1) Установка (всё выполняется на сервере): 1. Рекомендую использовать PGSQL 8.3 и выше. Создаем пустую БД через PgAdmin, а не через 1С!!! Выполняем запрос создающий таблицу databases. Заводим пользователя с полными правами на эту базу. Все параметры прописываем в options.ini. 2. Правим пути к лог файлу. 3. Запускаем LogService.exe проверяем что всё запустилось. В системном трее появится иконка, через нее выполняем выход из программы. Заодно стоит проверить создался ли лог файл, в него должен расписать подробно ход подключения. 4. Разворачиваем базу 1С на сервере. Запускаем отладку и смотрим что получается.

Ссылка на архив

Чуть не забыл. Для корректной работы надо в "Панели управления-Администрирование-Службы компонентов" дать прова пользователю из подкоторого сервер 1С работает на объект TSession на локальное выполнение

Делать народу больше нечего, ага?

очередной лисапед

кроликов ищешь?

(3,4,5) Если Вам больше делать нечего или это не интересно то зачем писать? Жду конструктивных идей

Реализован в виде COM-сервера для серверного варианта использования. А зачем в виде com-сервера-то? Напрямую не судьба писать или неохота?

куда в саму же базу 1С? Если в саму базу то такой вариант не устраивает. База сама по себе немаленькая и ещё её раздувать это через чур. И в моем случае гораздо удобней её держать в отдельной базе.

по ADO писать в другую базу вместо "своего" COM сервера

как тогда реализовывать коннект? при каждом событии заного поднимать? Неполучится сессию хранить на сервере. накладные расходы будут очень большими.

не-не-не. , Там PGSQL. Но! Это не оправдывает автора, который не умеет юзать поиск.:

А как ты счаст хранишь коннект?

Сейчас число идендификатор сессии и СОМ сервер находя у себя его в кеше подхватывае уже поднятое соединение. ЗЫ в тестовом варианте конект каждый раз заного поднимается

предлагаю логирование в текстовый файл через wscript.shell, а по расписанию (например каждые 5 минут) - засасывание файлика в БД

запросом прямо из БД

заного - это сильно

Если один документ в базе имеет ТЧ 10000 записей и надо снять её полный снапшот? Размер такого объекта у меня полуается примерно 8-9 Мб. Как-то не хорошо получается.

быстрее записи в текстовый файл все равно ничего нет

Плохо, Fragster Есть

Да акак же распаралелить работу? Что будет если в этот момент ещё с 2 десятка человек в базе работают?

Есть. Прямая запись в БД.

7-ка в журнал регистрации как-то умудряетс записывать ))

По ADO писать в другую базу в ФоновомЗадании на сервере. Конект хранить во ВременномХранилище или в повторно возвращаемых параметрах, для этого - перейти на 8.2

Вот и фсё.

схема с ком объектом изначально не оптимальна, логируй в исходнй базе и асинхронно переливай таблицы логов в другую БД, для этого достаточно скрипта

да? и как она быстрее?

Запись в оперативную память - быстрее всего

ну а в L1 кеш - еще быстрее... только вот как это с долговременным хранением связано?

Что мешает каждый раз при необходимости записи лога - запускать Фоновое и писать сразу в базу через ADO?