Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Интересно, насколько это базу утяжеляет и замедляет? Особенно если запустить массовое перепроведение документов? И еще один нюанс, насколько я понял регистры сведений при их активном использовании очень сильно увеличивают журнал транзакций в скуле. Соотвтетствнно при перепроведении колласпс может наступить ну очень быстро.
(1) Ну вообще утяжеляет нормально, как говорится, за все нужно платить. В любую базу бездумно ставить такой механизм я бы не стал. По идее можно еще подумать перед записью обработать данные из журнала, «свернув» их в пределах одной транзакции и сделав только одну запись — получится гораздо экономнее. Еще если не нужна такая «сильная» детализация можно вообще убрать подписки на события — получится гораздо быстрее. И вообще вынести это все в отдельную базу :). Хотя у меня и в таком виде работает.
А что значит «нормально»? +10% объема? +20%? или + 60% объема базы? И как это хранить в другой базе? т.е. при записи открывать по com другую базу и писать туда? Т.е. увеличивать время проведения документа? Сейчас проскочила бредовая мысль — а может имеет смысл это делать через планы обмены ?
(3) Вы не так поняли, данные пишутся в регистр не в момент записи/проведения документов, в эти моменты срабатывают только подписки на события, которые пишут данные в стандартный журнал (хотя их как я писал выше можно вообще убрать), а в регистр данные попадают в момент запуска регламентного задания, которое соответственно срабатывает по расписанию. То есть по идее убрав подписки мы вообще никак не будем влиять на скорость проведения документов.
Вот, кстати, цифры примерно за 1,5 года работы этого журнала:
Кол-во записей: 3 050 142
Общий размер: 2 684 208,00 (в КБ)
1С Бух КОРП, пользователей около сотни, размер базы ~30 ГБ.
За цифры спасибо огромное. А на счет подписки не согласен. Подписка на событие наступает в момент проведения документа ( в нашем случае). Так что время проведения документа увеличится по любому.
Пардон, гоню в понедельник с утра
(7) Ничего страшного 🙂
А что нибудь, что фиксирует изменения в регистрах сведений существует?
(9) Что-то где-то однозначно существует, но в данном случае упор делался только на объекты ссылочного типа как наиболее востребованные для анализа их истории. Для регистров нужно что-то мудрить и вообще тут еще нужно подумать что вообще есть запись регистра сведений?
У нас регистр сведений должен находится под контролем так как в него попадают на некоторое время данные которые потом используются для расчетов с контрагентами.
(11) agr, значит Вам нужен какой-то другой механизм
День добрый, Скажите плиз по вашей разработке Журнал регистрации с фоновой загрузкой изменений (8.2 — толстый клиент). как увидить какие именно были сделанны изменения , а то в журнале видно просто событие данные изменены, а какие не понятно
Есть один минус у данного способа.
Когда ЖР загружается, запись в регистр сведений тоже генерирует запись в ЖР. Следовательно ваш ЖР (файл) вырастит примерно в полтора раза и далее будет расти быстрее чем раньше.
(14) Ну я у себя давно все это дело переписал, я уж и не помню что там в конфигурации понаписано, но по моему, в регистр пишутся данные только по событиям ссылочного типа, а обычный журнал просто усекается и все, поэтому 3 года работает, я б не сказал что прям беда какая-то. Хотя у всех свои случаи конечно.
(15) А что переписали, если не секрет? Идея мне нравится, но вот пугает вероятность огромных логов. Усекать их — значит терять информацию (ту которая не будет писаться в регистр). А для архивации придется писать скрипт.
(16) Ну по доброму конечно надо писать это в отдельную базу, то есть создать там одну таблицу с ключом по GUID объекта (или что-то в этом духе), если только про ссылочный тип речь, и потом регламентное задание запускается, коннектится к этой базе и в нее пишет то, что возьмет из типового журнала. Где то тут было на сайте что-то подобное, поищите. А потом сделать внешнюю печатную форму «История объекта», например, для всех документов и справочников, и для тех, у которых есть кнопка «Печать» соотв-но можно будет прям оттуда эту историю выводить в какую нить печатную форму, а у которых нет кнопки печать, те смотреть какой-то специальной обработкой, которая как и печатная форма будет ломиться в эту базу внешнюю и брать оттуда данные. Как-то так 🙂
Очень всё понравилось. но добавил в регистр сведений журнала отдельно номер документа, чтобы видеть , если изменён номер документа.
(18) newtype, ну я уже неоднократно писал, что не претендую на какую-то оригинальность и что у всех свои задачи 🙂