gifts2017

Мега регистрация изменений средствами языка 1С

Опубликовал Александр (alex_serb) в раздел Администрирование - Журнал регистрации

Мега регистрация изменений реквизитов и справочников в базе исключительно средствами языка 1С.

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

Кратко принцип регистрации следующий.

Информация об изменениях в справочниках регистрируется в технологическом справочнике истории введением новых записей. Информация об изменениях в документах регистрируется в технологических документах. Дата технологического документа совпадает с датой рабочего документа. Технологический документ создается свой в каждой базе УРДБ, свой для каждого пользователя, дополнительный, если в данный момент технологический документ, удовлетворяющий условиям выше, заблокирован. Если происходит смена даты к-либо рабочего документа, то последующие изменения регистрируются в технологическом документе новой даты. Таким образом, в базе может присутствовать один и более технологических документов в дне.  При выводе истории рабочего документа, записи ищутся  с учетом возможной смены даты рабочего документа.

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Mega History
.zip 40,00Kb
19.02.13
269
.zip 40,00Kb 269 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Serj (Serj1C) 21.12.09 07:14
Прикольно, я подобную для 8.1 писал ))
2. Евгений Мартыненков (JohnyDeath) 21.12.09 17:10
А что в ней "магавского"??
Я так понимаю, что смысл сводится к одному: добавить в процедуры "ПриЗаписи" элементов справочников и документов вызов глобальной ф-ии?
Если да, то для этого надо править всю конфигурацию и программную запись таким способом не отловить.
3. Kur Chata (KurchataQ) 21.12.09 17:50
Хорошая вешчь! Только работы много, но и результат того стоит.
4. Александр (alex_serb) 21.12.09 19:52
Программные записи и отловить нечем, главная задача - разборка работы простых пользователей
5. Alexandr Климчук (undo) 23.12.09 12:37
Особенно класно будет выглядить справочник в конце года когда ежедневный документооборот фирмы составляет 1500 документов 80% которых исправляется в следующие 2-3 дня.
6. Александр (alex_serb) 23.12.09 13:15
Изменения по документам хранятся не в справочнике, а в техдокументах (поэтому нет "узкого горла"). Всё это год работает в базе с объемом 1000-1500 накладных в месяц. И пока ничего не плохого не произошло.
7. Сергей Лосников (Lars Ulrich) 23.12.09 15:12
имхо, не люблю когда такие служебные данные хранятся в БД. зачем они там нужны? к примеру при загрузках/выгрузках эти данные только занимают лишнее время и место. не спорю, что сама идея и реализация создания детального логирования заслуживает быть отмеченной, но...
возьмем к примеру sql. данные по логам хранятся не в служебных таблицах БД, а в отдельном хранилище. может стоит изменить данную обработку таким образом, чтобы она так же оперировала с внешним хранилищем?
8. Kur ChataD (KurchataD) 23.12.09 17:55
Все реализовал у себя. Работает очень и очень не плохо.
9. Александр (alex_serb) 23.12.09 19:15
(7) Совершенно согласен! Это хорошая мысль от хранении изменений вне базы!
10. BlackAvgur (BlackAvgur) 25.12.09 18:26
11. Саня Пупкин (pupkinSana) 02.02.10 13:26
Да, в маленьких базках, есть смысл и возможность вести мегаисторию.. А в больших - нет.
12. Александр (alex_serb) 03.02.10 20:25
(11) По опыту - полгода назад проблема возникла на базе с SQL 2005 - похоже превышалось некое предельное количество строк в документе истории, лечением было выбрано доп. дробление документов истории по пользователям. К слову, для SQL 2000 такая болезнь не отмечалась
13. olga pt (pt_olga) 04.06.10 12:07
идея хороша! :!: буду пробовать
14. Михаил (Mikeware) 06.07.10 13:58
Оригинал этой "мегарегистрации" был опубликован на проклабе году в 2003.
Причем стабильно работающий...
15. Александр (alex_serb) 07.07.10 08:50
14. Это очень интересно мне как челу, писавшему всё с нуля. Умоляю, дайте ссылку, please!!!! Иначе, просто не поверю...
16. Kur ChataD (KurchataD) 16.05.11 22:39
Реализовал. Все неплохо. Один вопрос - например - прошло время, и регистрация изменений уже не актуальны и ,следовательно, не нужны и т.д. Как удалить регистрацию изменений за определенный период?
17. Eugeneer (Eugeneer) 16.05.11 23:56
(16) гы..вы разве не в курсе что это была замануха :D сначала она раздует базу в 50 раз а когда все начнет тормозить а система ооать что диски забиты придется искать программиста за деньги чтобы все это почистить)) Шутка. Нужно искать теперь вам обработку чистки регистра.
18. Сергей (Che) Коцюра (CheBurator) 17.05.11 00:04
плохо. использование технологических документов увеличивает проблемы блокировки общего журнала.
19. Kur ChataD (KurchataD) 17.05.11 14:11
(17) В принципе я и сам могу. Это не вопрос. Интересно есть ли готовая обработка - лень-матушка самому писать.
(18) Я не настолько силен в таких вопросах, сказать что с проблемы блокировки связаны именно с этими технологическими документами я не могу. Но я проводил замеры проведения узловых документов - рн,по,ро и т.д., и выявил такую, можно сказать, закономерность - наибольшее время при записи и проведении занимают именно записи в доки заведующие историей изменений. Это конечно удручает.
20. Sergey Goylo (grayglobus) 21.01.15 17:33
Спасибо за труды, лог писал во внешние файлы и их накопилось столько много, что просто СисАдмин завыл от тоски, а ваша разработка кстати
21. Alexey (zarius) 13.05.15 12:45
(20) если от размера внешних файлов завыл СисАдмин (значит событий регистраций много) - осталось подождать пока Вы завоете от размера БД и того что написано в (18)
22. Александр (alex_serb) 13.05.15 23:10
Отвечаю сразу. База, к которой приторочена эта регистрация, сейчас размером 60Gb (Server 2003. SQL 2005). В базе ежедневно прибавляется не малое количество накладных при 20 активных пользователях. Пока тормозов не наблюдается. Поэтому, чего заранее переживать, что в бесконечности две параллельные прямые когда-то пересекутся :):)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа