Вопрос назрел, други.

Да, про историю.
Стою перед выбором:
- использовать решение отсюда: http://wastie.ru/istoriya/164384/index.html
- или взять из УПП подсистему версионирования.

Кто -что думает?

по ссылке жоский копрокод

версионирование. и не надо лохматить бабушку

(0) Версионирование из БСП

(3) видимо, у ТС не УФ

Не УФ.

(1)Неотформатированно и поэтому нечитаемо.
Слямзили вот отсюда:-)
http://www.ravepoint.narod.ru/aticles/tricks/methods/keephistory.htm

Проверка совпадения версий при записи объекта может выйти боком ой-ой-ой как

(0) http://infostart.ru/public/63420/

http://infostart.ru/public/151285/

http://infostart.ru/public/71458/

(5) Покер. Подсистема из БСП прекрасно встраивается, формы нарисовать - вообще не проблема.

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

(7) А что такого - перед записью делаем сравнение и пишем только то, что поменялось.

(6) дело не в форматировании а в том, что этот код из 150 практически одинаковых строк можно переделать в код из 20 строк

кроме этого, существуют подписки на события, куда спокойно можно это дело положить

(15) Подписка позволяет получить факт изменения, а данные - их всё равно придётся выбирать по метаданным.

(15)Я позднее так и сделал. :-)  Все руки не доходят статью поправить.

(16) да ладно?

(18) Ну а как иначе - подписка на событие ПриЗаписи.
Получаем элемент - можем или весь его в xml сложить или сравнивать с тем, что было до этого (а до этого где-то нужно взять).

(19) значит про событие ПередЗаписью ты кагбэ не в курсе?

(20) Как бы в (13) я про это и писал.
Только перед записью - это ещё не факт, что запись состоялась.

(21) ну и что? не состоялась значит не состоялась. делов то

(22) Нужно где-то сохранять изменения, полученные по подписке ПередЗаписью и писать их в базу уже по ПриЗаписи (хотя можно обойтись флагом)

(23) не вижу проблем. ХЗ отняли?

точнее ВХ

(24) А как узнать, что запись не прошла ?

(25) Где сохранить - это уже отдельная тема - для реализации, а до этого, нужно понять, что делать "в исключительных ситуациях".

(27) ПередЗаписью заполняешь ВХ
ПослеЗаписи переносишь в ХЗ и делаешь запись в РС ИсторияИзменений

(28) Это я уже понял, а что делать, если ПередЗаписью прошло (потом кто-то что-то отменил), а ПриЗаписи уже не дошло - остаётся значение "на память", а потом база становится очень большой - или при запуске следующего сеанса нужно чистить всё, что в прошлый раз было незафиксировано.

(29) если ПриЗаписи не прошло то ПослеЗаписи не возникнет

Единственная проблема подсистемы версионирования, что через некоторое время большая часть базы (до 80%) будет именно версиями объектов

(31) И в чём проблема - чистить базу от старых версий не так уж и сложно - маловероятно, что кто-то будет искать изменения полгода назад.

(31) ну можно ведь без фанатизма настроить

(32) Как только почистишь, так сразу и потребуется )))

Есть решение - экспорт данных в другую базу

(34) Backup-ы никто не отменял.

Кстати, система версионирования с выгрузкой изменений вполне годится как система BackUp-а в реальном времени.

(35) Но почему то стандартная подсистема такого не умеет

(37) лучше система версионирования с автоматическим сохранением в другую базу

(38) Другая база - это очень нестандартное решение для 1С.

(40) ты это скажешь когда будет запись во внешние источники данных?

(39) Не обязательно - можно регламентом - только "звери" про доступ к другой базе вообще ничего не знают, а сервер, где живёт регламент - знает, но ничего исправить не может - да и будет всего одно подключение вместо нескольких (по количеству пользователей).

(41) Когда будет - тогда можно будет считать, что 1С уже "созрела", а пока - только всякие Web-сервисы.
Хотя, некоторые "умные" базы данных позволяют в себя писать запросом на чтение (SELECT).

(42) с чего ты взял что одно? выполняй на клиенте и будет по количеству пользователей.

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

(0) По ссылке жесть. Как минимум регистр сведений, а не реквизит. Парсить потом не придутся, если несколько изменений.
Ну и подписку на событие, конечно же.

Рекомендую разработку:
http://softonit.ru/journal.html

Я пока поставил вариант от УПП.
Скорость записи немного, да снизился.

Может быть, когда-нить 1С дорастёт до встроенного отслеживания изменений внутренними механизмами, чтобы был, так называемый аудиторский след.

(49) а причем тут аудиторский след и 1С?
нужно - реализуй программно... в чем собственно проблема то ?

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

(45) а в чем проблема? в 1с клиентом можно гадить а в базу с версиями нет?

(52) Ну да, чтобы в базу журналирования никто лишний раз не лазил.

(50) Реализовать программно: нужно програмить самому или платить другим. А ларьку это накладно. Но функционал очень нужный. ИМХО, скоро в типовых будет появляться штатно.
Так что тема полезная и нужная.
Вариант по ссылке в (0) жесть, ИМХО к использованию не годен. Но сама идея очень хорошая.

(51) я подозреваю что в платформе сапа тоже нет аудиторского следа на уровне платформы и языка - а все реализовано просто напросто программно...

не ?

(55) работал в SAPе, там есть аудиторский след реализованный на уровне ядра.

(56) а как это выглядит?

(55) Как бы, если есть SQL-база, то в ней есть триггеры, которые работают тогда, когда ничто другое уже не работает.
И работают так, как надо - только у 1С есть файловый вариант, где это не работает.
Пока файловый вариант "не забьют камнями", будет проблема.
А все предпосылки есть - сервер на пять рабочих мест.
Осталось - сервер на одно рабочее место - и в путь к светлому будущему.

(56) В любой SQL базе есть журнал транзакций, база знает, что и кто поменял, и только нужно эту информацию собрать.

(53) кажется у тебя в корне неверное представление о связке клиента и сервера...

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

всю ветку не читал. про типовое версионирование уже было?

(62) Это в вопросе уже :). Ветку он не читал...

(61) то есть есть аналог подписки на события который пишет события в специальный аналог регистра сведений?
и чем это принципиально отличается от типового версионирования которое тоже с точки зреиня конфигурации "зашито в ядро"  конфигурации 1С? :)

(64) скорее там аналог ЖР, только с преферансом и поэтессами

(65) какая разница для конечного пользователя?

(64) Насколько я понимаю, там триггеры везде понапиханы.

(64) Наверное - ничем. Кроме скорости. Версионирование работает довольно не шустро.

(60) Предположим клиент-сервер, мы подключаемся с сервера - но для каждого клиента подключение всё равно своё будет.

(68) пытаясь установить фильтр на журнал регистраций я бы так не сказал..

(70) Ну вроде в 8.3 ЖР пишется в MySQL?

(70) Я и говорю - ЖР работает в 1С медленно. Версионирование добавляет свои тормоза.

(69) н.и.а.с.и.л.и.л :(

(71) пока не заметил..
(72) вот именно.. а версионирование весьма шустро работает..

подключал версионирование на БП16, БП2, БП3 с большим документооборотом на все документы/справочники.. пользователи ухудшения быстродействия не заметили..
с УТ11 постоянно пользую - тоже разницы на уровне пользователя с включенными/выключенным версионированием не видно..

да, замедление есть ибо это дополнительные операции выполняются, но они пользователю незаметны

(74) Я делал замер - после включения на 1-4% медленнее проводятся документы.
Хотя я еще пробовал одно хорошее решение от Куканова Андрея.
Неплохая с точки зрения использования, но тормознутая в части реализации. Там столько циклов крутятся при каждой записи, что версионирование гораздо проще - тупо записал версию документа. А сравнение делать уже в отчетах.

(73) Ты в (60) Пытаешься сказать, что в связке клиент-сервер можно подключаться к другой базе на сервере.
Можно, только количество подключений будет по количеству клиентов.

(75) 1-4% это простому пользователю не заметно.
об чем и речь...

(75) Можно тупо писать версии, а вечером в регламенте их уже "потрошить" на детализацию изменений. Объект в xml одной командой пишется - поэтому - должно быть быстро - конечно, циклы тоже есть, но они уже внутри платформы.

Вообще, хорошее версионирование заметно только по размеру BackUp-ов.

(78) раньше так и было..
дописывал в версионирование свои обработки на выявление дублей версий..

потом из за нытья 1Сников на тему "зачем оно пишет столько одинаковых версий, пусть сразу проверяет ибо база растет и пухнет" разработчики БСП видимо это включили штатной функцией видимо посчитав что замедление незначительно..