П ервая статья принесла один отклик, однако он оказался настолько концептуальным, что пришлось сесть за написание второй части. У новой технологии нет ни одного из недостатков, упомянутых в первой статье. Кроме того, описанную идею можно использовать и в других целях. Например, для организации детального журналирования изменений БД, совершенных пользователем.
автор статьи: Фёдор Езеев fe@alterplast.ru опубликовано: апрель 2003
Первая мысль – анализировать документ в момент записи, и в зависимости от того, что было изменено, принимать решение: перепроводить насильно, или без этого можно обойтись.
Первое решение, пришедшее в голову было таким: нужно отлавливать момент измененияреквизита, и в зависимости от того, какой реквизит – изменять (или не изменять)некую переменную формы документа. В процедуре ПриЗаписи() анализировать эту переменную,и, в зависимости от ее состояния, разрешать или запрещать сохранение без перепроведения.
Однако, уважаемый Mx@mail.ru и здесь проявилмогучий разум, он предложил еще одну здравую мысль (просто результат он знал заранее ;-). Мысль такая: в момент записи у нас есть один документв двух состояниях, которые можно довольно просто сравнить. Первое состояние –Контекст документа. Это то, что получилось после внесения изменений. Второе состояние –- записанный документ в базе данных.
Теория кончилась – берем в руки клавиатуру и пишем код. Начнем с анализа реквизитов шапки.
Теперь я хочу понять, насколько критичны сделанные изменения. И сообщить только о критичных.
Ну и в заключение на основании сделанного анализа примем нужное нам решение.
Общая картина ясна. Осталось только дописать анализ общих реквизитов и табличной части документа. Проблема может возникнуть разве что со сравнением табличной части. Тут главное – не забыть о том, что кроме изменения строк бывает еще и удаление и добавление.
Кусочек, сравнивающий строки, будет выглядеть примерно так (предполагаем, что любоеизменение табличной части требует перепроведения):
Преимуществами этого метода можно признать:
Автомобили
Бизнес