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

(0) Напиши Нуралиеву.

(0) Журнал регистрации - это оружие последнего шанса.

(0) Журнал регистрации оптимизирован под быструю запись.

Скажи спасибо, если вообще найдет, а не вылетит с ошибкой.

зы: есть обработка, которая выгружает журнал в XML с отбором. Работает гораздо быстрее

Пока - это оружие, которое стопроцентно вешает сервак напрочь, ему надо по разряду вирусов проходить

(5) Плохому танцору и журнал регистрации мешает.

(0) единственный выход это писать собственный журнал регистраций на основе регистра сведений или справочника, а типовой отключать пока не поздно))

(7) Не единственный. Писал ещё на турбо-паскале программулину, быстро вытаскивающую всё необходимое. Особенность программы - чтение блоками. Работала очень шустро.

(5) вы наверно отбор делаете, а надо поиском искать. Ну как текст в конфигурации ищете.

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

(5) руки на прямоту проверил? у меня и на больших базах все быстро работает

(10) Чтоб сделать независимым от транзакций, точней от отката транзакции. Ваш Кэп.

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

(13) только если писать за пределы этой БД. РС в этой БД не взлетит

(13) Я не меряюсь "крутизной". ) Твоё решение мне не нравится зависимостью от хранилища. Текстовый файл надежнее.

(0) ставь разделение ЖР по времени и периодически чисти... больше нет вариантов пока

(14) че это РС не взлетит?

(17) > (12). Ну попробуй записанть в него при ошибке проведения документа. Транзакция откатится, запись в регистр тоже

ЖР не зависит ни от чего, запись в него безусловна

(19) Но это же не круто! )

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

1. Имхо, желательно устанавливать разумные периоды хранения журнала
2. Крайне желательно в отбор добавлять дату

напишу ка я свой журнал регистрации на досуге с блэкджеком

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

(11) Руки на прямоту проверял, десять лет уже как 1С занимаюсь, были периоды сильной кривизны рук, были откровенного выпрямления конечностей, но за все десять лет ни разу не видел, чтобы журнал регистрации даже в маленьких базах быстро работал, вне зависимости от того я эту базу сопровождал или не я...

У меня история изменения документов пишется другими способами, ЖР не используется. Всегда можно быстро посмотреть кто и что поменял.

(18) насчет отката не совсем согласен, ставим подписку на событие и пишем себе при разным событиях все что хотим, то ли дело порядок вызова у таких обработчиков дальше чем у модуля и если ранее было исключение то записи "Попытка записи документа" не будет вообще

Где то на инфорсрарте была конфигурация, загружающая и работающая с журналом, вроде как минут 40 не было ни разу

(18) + конечно старт транзакций не понятно как отлавливать и в стандартном ЖР куча настроек и параметров, но кому оно надо зачастую, всех интересует Кто и Когда

(27) Подписки идут в рамках транзакции события, если чо. Подписка ПриПроведении в одной транзакции с проведением дока, откат произвойдёт везде
(24) правильное решение помоему
(29) Кто, Когда, Что - Версионирование на РС как раз, ЖР другую функцию выполняет

Хех. Зачем от ЖР отказываться? Затрахают юзверы. Выгружаешь его порциями и тут-же загружаешь куда тебе хочется. Хоть в регистр, хоть в ж... И извращайся там как тебе хочется :)

(0) версионирование запили