Переключение на Главную Страницу Страницы: 1 [2]  ОтправитьПечать
Горячая тема (более 10 ответов) Журнализация изменений документов (число прочтений - 7136 )
Alex_Bob
Full Member
***
Отсутствует



Сообщений: 136
Местоположение: Липецк
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #15 - 25. Ноября 2008 :: 12:46
Печать  
Меня вот всегда интересовало, как в подобных системах должны отыгрываться административные действия типа восстановление из архива, загрузка/выгрузка, обмен УРБД, обновление MD?
  

Необходимо время, чтобы восстановить хаос. (с) Дж. Буш (младший)
Наверх
 
IP записан
 
trdm
1c++ power user
qt1l developer
1c++ moderator
Отсутствует



Сообщений: 2343
Местоположение: г. Ростов-на-Дону
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #16 - 25. Ноября 2008 :: 13:08
Печать  
Alex_Bob писал(а) 25. Ноября 2008 :: 12:46:
Меня вот всегда интересовало, как в подобных системах должны отыгрываться административные действия типа восстановление из архива, загрузка/выгрузка, обмен УРБД, обновление MD?

шо значит отыгрываться?
  
Наверх
IP записан
 
Alex_Bob
Full Member
***
Отсутствует



Сообщений: 136
Местоположение: Липецк
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #17 - 25. Ноября 2008 :: 13:56
Печать  
1. После загрузки/выгрузки или восстановления базы из архива некоторая часть изменений, сделанных пользователями может стать неактуальной, хотя с другой стороны, появляется шанс их восстановить.
2. Если система на триггерах в БД, то после изменения MD триггеры надо скорее всего восстанавливать заново.
3. Как отслеживать программные изменения данных, если используется перехват интерактивных действий пользователей. (Например ОбработкаДокументов)

Я собственно хотел спросить, заморачивался ли кто-нибудь по этому поводу и наступал ли на подобные грабли?
  

Необходимо время, чтобы восстановить хаос. (с) Дж. Буш (младший)
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: Журнализация изменений документов
Ответ #18 - 25. Ноября 2008 :: 15:25
Печать  
Alex_Bob писал(а) 25. Ноября 2008 :: 13:56:
1. После загрузки/выгрузки или восстановления базы из архива некоторая часть изменений, сделанных пользователями может стать неактуальной, хотя с другой стороны, появляется шанс их восстановить.

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

Цитата:
2. Если система на триггерах в БД, то после изменения MD триггеры надо скорее всего восстанавливать заново.

Думал над этим - триггеры-то не беда, можно и пересоздать.
А вот то, что после реструктуризации базы надо заодно реструктуризировать и журнал - это, пожалуй, посложнее будет.
toypaul, как я понял, решал эту задачу: первоначально и триггеры и журналы изменений после реструктуризации у него очищались и создавались заново.
Сейчас, как я понимаю, информация в журнале реструктуризируется, но сохраняется.

Цитата:
3. Как отслеживать программные изменения данных, если используется перехват интерактивных действий пользователей. (Например ОбработкаДокументов)

Пока не понял, в чем отличие от какого-либо другого метода изменения документа.
А в чем может быть проблема?

Цитата:
Я собственно хотел спросить, заморачивался ли кто-нибудь по этому поводу и наступал ли на подобные грабли?

Пока вот только собираемся, тем интереснее обсуждение.
  

De quelle planète es-tu?
Наверх
 
IP записан
 
dnp
Senior Member
****
Отсутствует


.

Сообщений: 479
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #19 - 26. Ноября 2008 :: 07:12
Печать  
kms писал(а) 25. Ноября 2008 :: 15:25:
А вот то, что после реструктуризации базы надо заодно реструктуризировать и журнал

А кто мешает развернуть все объекты в простую длинную таблицу в которой - один реквизит - одна строка?
Я таким образом развернул и табличные части и шапку и общие и системные реквизиты. Реструктуризация не требуется, хотя получение данных может вызвать некоторый гемороген -- собирать шапку документа из нескольких строк журнала, а табличную часть - из ещё более нескольких строк. Я посчитал, что частота обращения на чтение к журналу на столько низкая, что сложность извлечения ни что по сравнению с простотой обслуживания.
  
Наверх
ICQ  
IP записан
 
Alex_Bob
Full Member
***
Отсутствует



Сообщений: 136
Местоположение: Липецк
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #20 - 26. Ноября 2008 :: 08:11
Печать  
Цитата:
Цитата:
Цитата:
3. Как отслеживать программные изменения данных, если используется перехват интерактивных действий пользователей. (Например ОбработкаДокументов)

Пока не понял, в чем отличие от какого-либо другого метода изменения документа.
А в чем может быть проблема?


Как я понял, в ветке рассматривается 2 альтернативных метода создания журнала изменений.
1. Перехват всех интерактивных событий и формирование журнала методами 1С. Минус в том, что таким методом нельзя перехватить изменения документов программным путем (например при запуске пользователем обработки массового перепроведения документов). Можно конечно изменить все используемые обработки и найти все места в конфигурации, где встречается метод Записать(), но это большой гемор с дальнейшим сопровождением.
2. Перехват всех событий с базой с помощью триггеров SQL и формирование журнала средствами SQL. Невозможно использовать для DBF и сложность с реструктуризацией.

Оптимальным наверно был бы подход как в восьмерке - там на уровне модуля объекта перехватываются любые события записи в базу. Но можно ли это реализовать в семерке без подмены dbeng32 я не знаю.

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

Необходимо время, чтобы восстановить хаос. (с) Дж. Буш (младший)
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Журнализация изменений документов
Ответ #21 - 26. Ноября 2008 :: 08:19
Печать  
Alex_Bob писал(а) 26. Ноября 2008 :: 08:11:
Цитата:
Цитата:
Цитата:
3. Как отслеживать программные изменения данных, если используется перехват интерактивных действий пользователей. (Например ОбработкаДокументов)

Пока не понял, в чем отличие от какого-либо другого метода изменения документа.
А в чем может быть проблема?


Как я понял, в ветке рассматривается 2 альтернативных метода создания журнала изменений.
1. Перехват всех интерактивных событий и формирование журнала методами 1С. Минус в том, что таким методом нельзя перехватить изменения документов программным путем (например при запуске пользователем обработки массового перепроведения документов). Можно конечно изменить все используемые обработки и найти все места в конфигурации, где встречается метод Записать(), но это большой гемор с дальнейшим сопровождением.
2. Перехват всех событий с базой с помощью триггеров SQL и формирование журнала средствами SQL. Невозможно использовать для DBF и сложность с реструктуризацией.

Оптимальным наверно был бы подход как в восьмерке - там на уровне модуля объекта перехватываются любые события записи в базу. Но можно ли это реализовать в семерке без подмены dbeng32 я не знаю.

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


Да можно при проведении пиши куда либо что либо
но во первых это плохо если много писать так как идет транзакция очень дорого,
во вторых документ(реквизиты документа) может меняться и в модуле проведения а если мы запишем раньше то получим не то
значение.
Третье сам сказал что делать при откате базы данных.
Четвертое при подгрузке УРБД событие проведение не получишь
и следовательно данные в другой таблице будут неправильными
  
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: 1 [2] 
ОтправитьПечать