Я думаю что ответ нет, но всеже спрошу. Есть у меня некая функция завернутая в Транзакцию, по мере её выполнения я пишу лог - в моем случае это объект базы типом Документ.
Надо чтобы лог писался вне зависимости от того зафиксируется ли транзакция в итоге или нет.
Пока придумал запуск записи в лог через фоновое задание - но этот вариант не особо радует. Есть ли другие возможности оперативной записи данных в базу при наличии Транзакции?

(0) А ну естественно у меня 1С сервер

Только другим сеансом - а значит только фоновым заданием.

Журнал регистрации, типа православно верный способ, одобренный самой 1С.

ЖР конечно

(0) Лог.Записать() делай после отмены/завершения транзакции

(2) Блин жалко

(3) (4) Ну это мы покапаем, просто аналогичный функционал сделан для Фонового задание. Ну всмысле запускаю фоновое задание (весь код в транзакции), которое через запуск фоновых обновляет регистр сведений куды пишет текущий процент своего выполнения. Я и для этого тож спрашивал просто.

(5) А вдруг до отмены/завершения по какимто причинам процесс 1С вообще упадет, и логи получаются не запишуться.

(8) т.е. в транзакцию ты обернул, а исключение не обработал?
ну пиши сразу и запоминай, что записал. если делаешь отмену - повторно пиши. а вообще про ЖР тебе правильно говорят, твой велосипед никак не лучше.

(9) Да завернул я в исключение.
Давайте рассмотрим случай тогда с процентом выполнения фонового задания. Там то только через другое ФН получается?

(10) Мож конечно через временное хранилище попробывать, но сеанс проверяющий процент не является родителем для сеанса выполняющего ФН

(11) попробуй через ЖР, точно тебе говорю

(12) Я ща не про лог, а про процент выполнения фонового задания

(0) Попытка...Исключение...КонецПопытки
Не?

(14) Да этого г_а_в_н_а у меня везде понатыкано, вопрос то в другом

(13) первое, что приходит в голову, сделать форму, на ней индикатор, ее открывать и из ФЗ индикатор обновлять. хз, насколько рабочая идея.

(16) Ну ты и даванул, у меня ФЗ вообще из операции web-сервиса запускается, и процент считывается другой операцией. Корочь нету у меня интерфейса.

(17) какой тебе тогда индикатор, если интерфейса нет? кто об нем знать то должен?

(18) есть кому не переживай

А не проще эту лабуду через текстовые файлы сделать?

В чем необходимость писать эту инфу именно в БД?

Функция ...()
    ТЗЛог = Новый ТаблицаЗначения;
    ...
    НачатьТранзакцию();
    ...
    Если...
    ЗафиксироватьТранзакцию()
    Иначе
    ОтменитьТранзакцию()
    КонецЕсли;
    Для Каждого СтрЛог Из ТЗЛог Цикл
       ...
    КонецЦикла;
КонецФункции
Не?

(20) Эт д_е_р_ь_м_о какоето, а вдруг у меня кластер серверов, что им ещё и общий сетевой каталог давай. Да и как там с блокировками будет? сразу с исключением падать будет если др сеанс ведет запись в файл, или перезаписывать будет (всмысле открывают файл 2 сеанса, а данные в итоге только с последнего)

(22) Да блин я уже не про лог говорю посмотри в  (10)

пиши в скл напрямую

В жёсткий диск магнитом вводи!

Корочь я понял мутить через фоновое

(23) Те же логи обычно пишутся без "удержания" файла. Записал-отпустил. Это быстрая операция. При конкурентном доступе - в пределах таймаута доступа. Писать разными сеансами в один файл - не вижу необходимости на твоих задачах. Вот с кластером серверов - да, незадача...
Если подумать, то таки да - фоновые задания привлекательней :)

(28) Ну пока все через фоновые сделано, я даж подумываю мож в коде открывать доп коннект через ком к 1С, и кода основной код завернут в транзакцию, через доп конект обновлять регистр статуса выполнения процесса, получается вроде как я создаю сам Фоновое задание которое держу за "я_й_ц_а", единственный минус этой затеи что я в коде буду ожидать выполнения процедуры вызываемой в доп коннекте (но на это н_а_с_р_а_т_ь, думаю ожидание завершения процедуры перезаписи одной строки РС ничтожно). Встают др вопросы: например как сделать доп коннект в коде от тек пользователя - ведь пароль то мы не знаем.

(29) добавь еще один веб сервис, который только будет писать логи и его дергай.

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

(29) Я думал об этом. Но стремное это дело - писать в таблицы 1С со стороны. Фиг его знает, чего там сервер приложений кэширует и как. Если уж писать, то в служебную БД.
Но если прикинуть все в целом, получается что проще таки через фоновое задание :)

А, стоп. Пропустил, что ты через COM-соединение 1С хотел писать. Все равно через фоновое проще, ИМХО.

(33) Да я имел ввиду заменить вызов фоновых (раз 30) созданием доп коннекта.

Один коннект вместо множественных запусков фоновых? Тогда имеет смысл. А запускать можно под служебным пользователем.

Плохо, что COM. Это привязка к винде.

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

Что касается (0) Сделай отдельное АДО соединение и пиши в таблицу MSSQL в отдельной базе(что бы лицензионное соглашение не нарушать:)).

(37) Ему не совсем логирование в чистом виде нужно. Ему вообще нужно отображать на клиенте ход выполнения фонового задания.

(38) Не на клиенте, а в второму сеансу дать возможность считывать ход выполнения первого

(37) А что фоновые тоже лицуху жрут?