Журнал регистрации изменений во внешней информационной базе 1С (управляемые и обычные формы, демо-сервер)

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

Давно известно, что стандартный журнал регистрации фирмой 1С достаточно плохо продуман и реализован. Допустим, он предоставляет информацию об идентификаторе транзакции, но не предоставляет сведения о том какой реквизит был изменен, что, по моему мнению, более важно. Далее самый больной вопрос, как быть, если пользователей работает много, изменений производится тоже достаточно много и Вы пытаетесь, в стандартном журнале найти, кто изменил документ? Как это не печально, но подобная, в общем случае, тривиальная задача займет у Вас очень много времени, т.к. открывается и ищется все чудовищно долго. Простой отбор по какому-нибудь документу может занимать 5-10 минут, а время, как известно, деньги… Так же в стандартном журнале нельзя увидеть, что было изменено в объекте. Т.е. на вопрос, какой конкретно реквизит или строчка в табличной части были изменены, ответа мы не получим. Зачастую нерадивые сотрудники этим пользуются, аргументируя, что они просто открыли документ и вместо кнопки «Закрыть» нажали «OK» ничего не изменив. Не получится настроить встроенный журнал, чтобы из открытого документа или справочника можно было бы нажатием одной кнопки увидеть всю историю изменений. А это очень удобно!

ТОП-продаж! ТОП-5 продаж разработок Инфостарта! Мы регулярно добавляем новые возможности!

Основные возможности

Прежде всего, хочется перечислить, все основные механизмы с обоснованием, почему используются именно они.

1) Подсистема работает в конфигурациях 8.2 и 8.3 в толстом, тонком и WEB-клиенте (обычные и управляемые формы). Сейчас сложилась парадоксальная ситуация. Есть конфигурации, которые используют обычные формы, есть которые работают на управляемых формах, а так же есть те, которые работают и так и так. Наша подсистема позволяет работать в любом режиме, причем если будет запущена в толстом клиенте, то будет интерфейс и формы толстого клиента, если в тонком или WEB, то на управляемых формах. При этом практически не будет никакой разницы с точки зрения функциональности. Вот как выглядит журнал регистрации в толстом и тонком клиенте:

2) Регистрируются изменения для следующих видов объектов: константы, справочники, документы, планы видов характеристик, планы счетов, планы обменов, планы видов расчета, бизнес-процессы, задачи и регистры сведений.

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

4) При помещении во внешнюю информационную базу история изменений объектов «сжимается». Что это значит? Приведем пример. Допустим пользователь «А» создал документ, заполнил его и провел. Затем пользователь «Б» его открыл и изменил в нем один реквизит, после чего также провел. При этом наша подсистема позволит Вам увидеть, только то, что пользователь «Б» изменил без показа всех реквизитов. Это позволяет точно сказать, что было изменено.

5) Есть возможность настроить список объектов, по которым не нужно отслеживать изменения. Скажем больше: такая возможность просто необходима! Так как в типовых конфигурациях есть, например, справочники «Сохраненные настройки» или «Рабочие места», по которым нет необходимости вести историю изменений т.к. эти справочники служебные. Так же можно ограничить запись не только объектов, но и конкретных реквизитов!

6) Просмотр изменений прямо на формах объектов. Позволяет при открытии объектов из журнала регистрации подсветить на форме измененные объекты красной рамкой. При этом в подсказках измененных объектов пишется дата изменения, кто изменил, что было раньше и что стало после изменения.

7) Возможность записи событий входа и выхода пользователей в информационную базу (при желании можно отключить).

8) Гибкая система отборов: по пользователю, компьютеру, типу метаданных, объекту, представлению, событию за период. Все отборы устанавливаются на фантастической скорости! Это не десятки минут ожидания работы типового механизма. Все просто и быстро.

9) Минимальное влияние на производительность. Вы практически не почувствуете разницу при работе с нашей подсистемой и без нее. При разработке подсистемы мы руководствовались тем, что перенос событий во внешнюю ИБ 1С не будет оказывать никакого влияния на размер основной информационной базы.

10) Для типовых конфигураций разработаны внешние печатные формы, которые позволят просматривать истории изменений объектов при печати. Т.е. для любых объектов типовых конфигураций (БП, ЗУП, УПП, УТ, КА, БГУ, УНФ) можно за пару щелчков мыши, нажав на кнопку «Печать» и выбрав пункт «Просмотр изменений» открыть изменения данного объекта.

11) В подсистеме используется уникальный механизм защиты от записи истории объектов в клонах информационных баз. Часто, необходимо сделать копию информационной базы для тестирования доработок, экспериментов и т.д. При этом наша подсистема будет работать только в работающей конфигурации, в копиях-клонах работать она не будет. Эта особенность пригодится программистам, т.к. позволит не думать, что копия будет добавлять свои события в журнал регистрации.

12) "Откат" изменений объектов в конфигурации на предыдущие версии по данным журнала регистрации.

13) Один журнал регистрации для нескольких информационных баз 1С.

14) Поддержка ведении истории в распределенных информационных базах (РИБ) с двумя способами ведения истории.

Как это выглядит на примере?

Возможности - это хорошо, но как это выглядит в реальной жизни? Вот вопрос, который беспокоит всех. Мы постарались сделать работу с журналом в максимально простом и понятном виде. Рассмотрим несколько примеров.

Пример 1.

Часто встает задача о контроле даты запрета изменения. Рассмотрим пример, как решает ее наша подсистема. Допустим кто-то из пользователей изменил дату запрета. В журнале появится событие изменения регистра сведений, которое выглядит следующим образом:

Глядя на это событие, очень просто ответить на вопрос: кто изменил дату запрета редактирования данных? Мало того, можно увидеть предыдущее значение, а так же: кто, когда, на каком компьютере изменил запись в регистре. Можно также сделать отбор по текущим измерениям записи регистра и увидеть предыдущие записи, кто и когда изменял данную запись. Если какие то измерения/ресурсы/реквизиты по сравнению с предыдущим изменением изменены не были, то они не будут перенесены при записи. Действительно, зачем Вам видеть в событии то, что не было изменено по сравнению с прошлым изменением?

Пример 2.

В организации кто-то поменял в документе "Счет на оплату покупателю" количество из-за этого, какие то позиции могут быть не проданы! Причем крайних не найти никогда! Идем в журнал. Делаем отбор по всем документам "Счет на оплату покупателю" и видим:

Открываем событие:

Видим, что в искомом документе пользователь "Абдулов" изменил в 1-ой строке табличной части "Товары", реквизит "Количество" с 300 на 100. При изменении количества поменялись так же и суммы.
Все достаточно просто и понятно.

Это всего лишь примеры, но именно они показывают всю мощь подсистемы.

Вопрос-ответ

Вопрос: Сложно ли интегрировать подсистему в конфигурацию?
Ответ: Абсолютно ничего сложного. В руководстве для пользователей установка описана до мелочей. Ее сможет установить человек, который никогда прежде ничего подобного не делал.

Вопрос: А код подсистемы открыт?
Ответ: Да. Подсистема полностью открыта.

Вопрос: Будет ли система и дальше развиваться и обновляться?
Ответ: Конечно! Подсистема постоянно развивается и обрастает новым функционалом. После покупки в качестве бонуса первые полгода обновления предоставляются бесплатно. После окончания бесплатной поддержки и получения обновлений, Вы можете их продлить: 1 год - 7800 руб, 2 года - 11800 руб. В новых версиях мы улучшаем подсистему, добавляем новые возможности, а так же адаптируем подсистему к изменениям в платформе 1С.

Вопрос: Подсистема работает и на обычных формах и на управляемых? На каких конфигурациях?
Ответ: Функционал и для обычных и для управляемых форм одинаковый, соответственно подсистема работает как на обычных формах, так и на управляемых. По скриншотам из публикации это видно. Кроме того, подсистема одинаково успешно будет работать в ЛЮБОЙ конфигурации, как типовой, так и не типовой.

Вопрос: Если в организации несколько баз, для каждой надо приобретать отдельно, или достаточной одной лицензии?
Ответ: В пределах одной организации достаточно одной лицензии, причем подсистему можно использовать во ВСЕХ конфигурациях организации. Если же в одной информационной базе ведется учет сразу нескольких организаций, то так же достаточно только одной лицензии.

Если остались еще вопросы, добро пожаловать в демо-версию!

Последние обновления

02.12.16 Версия 3.0.8.1

03.08.16 Версия 3.0.7.5

17.07.16 Версия 3.0.7.2

14.04.16 Версия 3.0.6.1

11.02.16 Версия 3.0.5.0

30.09.15 Версия 3.0.2.3

05.08.15 Версия 3.0.0.0

19.02.15 Версия 2.0.3.6

20.01.15 Версия 2.0.3.5

03.10.14 Версия 2.0.2.3

12.08.14 Версия 2.0.1.6

26.06.14 Версия 2.0.0.3

23.06.14 Версия 2.0.0.0

19.03.14 Версия 1.0.5.5

10.01.14 Версия 1.0.4.1

12.09.13 Версия 1.0.3.1

09.07.13 Версия 1.0.2.7

11.06.13 Версия 1.0.2.5

09.04.13 Версия 1.0.0.2

Важно! Обновления размещены по дате "сверху-вниз" (последние изменения вверху, первые внизу).

 Сделайте свою жизнь проще! Пусть работа будет приносить только удовольствие!

Гарантия возврата денег

Гарантия возврата денег

ООО "Инфостарт" гарантирует Вам 100% возврат оплаты, если программа не соответствует заявленному функционалу из описания. Деньги можно вернуть в полном объеме, если вы заявите об этом течение 14-ти дней со дня поступления денег на наш счет.

Программа настолько проверена в работе, что мы с полной уверенностью можем дать такую гарантию. Мы хотим, чтобы все наши покупатели оставались довольны покупкой.

Для возврата оплаты просто свяжитесь с нами.

Лицензии

Наименование Файл Версия Размер
Руководство пользователя, редакция 3.0
.pdf 4,56Mb
19.07.16
581
.pdf 3.0.7.5 4,56Mb 581 Бесплатно
Журнал регистрации изменений во внешней информационной базе 1С
07.12.2016
3.0.8.1 15000 руб.

Моментальная
доставка

Поддержка и получение обновлений подсистемы "Журнал регистрации изменений во внешней ИБ 1С" сроком на 12 месяцев СТАНДАРТ
16.12.2016
7800 руб.
Поддержка и получение обновлений подсистемы "Журнал регистрации изменений во внешней ИБ 1С" сроком на 24 месяца СТАНДАРТ
16.12.2016
11800 руб.

См. также

Добавить вознаграждение
Комментарии
1. Князев Евгений Юрьевич (noblekey) 97 04.02.13 15:30 Сейчас в теме
а чем ваша разработка отличается от http://infostart.ru/public/71458/?
2. Виталий Барилко (Diversus) 2213 04.02.13 15:35 Сейчас в теме
(1) Отличается очень многим.

1) Работа с журналом регистрации в базе MS SQL Server быстрее чем в базе 1С через сom-соединение.
2) Есть запись данных регистров сведений, чего нет вообще нигде
3) Пытались сделать интерфейс как можно более приближенный к типовому журналу регистрации
4) Ну и дешевле)))
3. Инна Дмитриева (InnaD) 04.02.13 17:49 Сейчас в теме
4. andrey dyak (dyak84) 04.02.13 18:59 Сейчас в теме
Здраствуйте скажете пожалуйста как нащет производительности у меня база 150 гб пользователи не будуть подвисать????????
5. Виталий Барилко (Diversus) 2213 04.02.13 21:22 Сейчас в теме
(3) На PostgreSQL не работает и пока не планируется делать для этой СУБД. Все делалось исключительно для MS SQL Server. Но даже если у Вас его нет, никто не мешает использовать версию Express, которая бесплатна.
(4) При правильной настройке хранимой базы с журналом регистрации и нашей подсистемы ничего не должно подвисать. У нас сделано кэширование соединения к SQL Server и используемых данных, которое в разы повышает производительность. Например, соединение с базой данных журнала регистрации, создается только один раз при записи первого объекта и работает весь сеанс не создаваясь вновь. Так же сделаны в отличие от типового журнала многие улучшения, который благоприятным образом отразились на производительности. Например, у нас не записывается постоянно в базу данных имя пользователя, имя компьютера и метаданные. Для них заведены отдельные таблицы, а в сам журнал записывается только ID этих данных. Это позволило существенно сократить размеры записываемых данных, а так же быстро выводить в отборах данные объекты.
migulja; Zircool; kirillbul; +3 Ответить
6. Павел Данилкович (pashoid) 7 06.02.13 01:44 Сейчас в теме
Эх, если можно былоб отключить штатный журнал. Вот это песня былаб.
7. 1С-у.к.и. 1С-у.к.и. (1cyku) 55 06.02.13 08:06 Сейчас в теме
Что произойдет с программой, если оборвется соединение с SQL сервером? Как обрабатывается, например, ошибка по таймауту?
8. Виталий Барилко (Diversus) 2213 06.02.13 11:03 Сейчас в теме
(6) Штатный журнал регистрации можно отключить (или изменить список регистрируемых изменений). Для этого необходимо зайти в режиме конфигуратора и в меню выбрать Администрирование>Настройки журнала регистрации...
Далее выбрать список событий, который необходимо регистрировать. Если ничего не хотите видеть выберите пункт "Не регистрировать".
9. Виталий Барилко (Diversus) 2213 06.02.13 11:10 Сейчас в теме
(7) Если оборвется соединение с SQL сервером, то:
1) Будет осуществлена попытка создать соединение повторно, если этот шаг исправит ситуацию, то продолжаем работать в штатном режиме
2) Если соединение с сервером будет потеряно, и повторное переподключение не даст результатов (например, что то случилось с машиной на которой установлен экземпляр SQL сервера), то события перестанут фиксироваться для данного пользователя, но работать с информационной базой 1С он продолжит без каких либо ошибок. Т.к. подсистема, подсистемой, но она не должна ни в коей мере влиять на основную работу.
10. KV1s (KroVladS) 22.02.13 12:53 Сейчас в теме
(9) Diversus,
Т.к. подсистема, подсистемой, но она не должна ни в коей мере влиять на основную работу.

лучше вынесите в настройки, может для кого то как раз принципиально чтобы не было ни одного действия без лога.
11. Виталий Барилко (Diversus) 2213 22.02.13 13:11 Сейчас в теме
(10) Все и вынесено в настройки
12. Виктор Лебедев (eeeio) 80 12.03.13 08:46 Сейчас в теме
выглядит отлично. жаль нам не нужно.
stas1kbob; +1 Ответить
18. Азбука Морзе 36 04.04.13 11:32 Сейчас в теме
У нас более 20 филиалов, на каждом как минимум типовая бухгалтерия и не типовая торговля. В связи с этим вопрос: на каждую базу требуется отдельная лицензия или достаточно одной для всех.
19. Виталий Барилко (Diversus) 2213 04.04.13 11:40 Сейчас в теме
(18) Достаточно одной лицензии на неограниченное число информационных баз для каждого юридического лица.
20. Виталий Барилко (Diversus) 2213 09.04.13 13:35 Сейчас в теме
Обновление подсистемы "Журнал регистрации изменений во внешней БД MS SQL Server", версия 1.0.0.2 от 09.04.13

[*] Исправлена ошибка конвертации даты, если в MS SQL Server формат даты отличается от '01.01.2013 00:00:00' (например для серверных ОС, у которых в языковых настройках стоит формат '2013/01/01 00:00:00' и т.д.).
Формат даты унифицирован и теперь не зависит от языковых настроек.
21. Александр Тарасюк (Aletar) 26.06.13 06:44 Сейчас в теме
Скажите, а если возможность использования одной базы журнала изменений для нескольких информационных баз?
22. Виталий Барилко (Diversus) 2213 26.06.13 10:15 Сейчас в теме
(21) Нет. Такой возможности нет. Для одной информационной базы - одна база данных MS SQL для журнала регистрации.
24. Виталий Васькович (mr_best_23rus) 29 28.10.13 06:38 Сейчас в теме
Здравствуйте! Купил вашу подсистему, при создании базы 1С наглухо зависает. Настраивал по инструкции. Что можно сделать?
25. Виталий Барилко (Diversus) 2213 28.10.13 10:30 Сейчас в теме
(24) Подобное поведение возможно при блокировании прямого доступа к серверу MS SQL, например, антивирусом. Напишите мне личное сообщение решим проблему.
26. Виталий Жуланов (VZhulanov) 06.11.13 19:09 Сейчас в теме
Подробно изучил инструкцию и все комментарии к вашей подсистеме и к подсистеме http://infostart.ru/public/71458/
У конкурентов понравилась возможность восстановления физически удаленных записей и возможность отката изменений. Но очень не понравилось хранение данных в базе 1С, так как есть собственный опыт подобного хранения истории изменений - база быстро достигает своих пределом по размерам, а у моих клиентов лицензии только на файловые 1Ски.

Вопросы по вашей подсистеме:
1. Планируется ли возможность отката изменений ? - не самое важное.
2. Планируется ли хранение самого первого состояния объекта, при его создании? У пользователей есть права на физическое удаление объектов, но иногда им злоупотребляют, и тогда данные можно было бы поднять из истории изменений, а не из бэкапа, как сейчас делаю.
3. Планируется ли регистрация изменений в распределенных базах ? Ибо некоторые объекты меняются в разных перифериях, а в центре хотелось бы видеть консолидированную информацию по всем изменениям объекта. Это очень важный пункт, так как периферий много, и отслеживать изменения довольно таки трудно.
4. Планируется ли возможность вести изменения нескольких 1С баз в одной внешней SQL ?
5. Через что идет работа с SQL сервером, будет ли подсистема работать под линуксом ?
27. Виталий Жуланов (VZhulanov) 07.11.13 10:21 Сейчас в теме
Идея по отслеживанию изменений для распеределлынх баз:

SQL базы имеют возможность репликации/зеркалирования.
Подробности не изучал, поэтому могу ошибаться в определениях.

Настраиваем эту саму репликацию на уровне SQL сервера и имеем одинаковые базы истории в центральном и периферийном объекте.
Главное чтобы идентификаторы, которые используются внутри SQL базы (если такие есть конечно) были уникальными.

Останется в процедурах загрузки обмена тоже добавить контроль на изменения объектов и сохранять их с признаком "изменение при обмене".

Опять же не в курсе есть ли такая возможность на бесплатных Express базах.
Если нет, то это еще один повод расширить универсальность подсистемы и научить ее работать с Postgress, тем более что структура таблиц и запросы будут не сильно друг от друга отличаться, а для распространения подсистемы это даст хороший толчок.
28. Dmitry Grabarev (dmitry-gr) 15.11.13 10:58 Сейчас в теме
Подскажите, что будет происходить если в процессе эксплуатации сервер хранения логов станет недоступным?
Как это скажется на производительности?
Что произойдет когда он снова включится?

29. Виталий Барилко (Diversus) 2213 15.11.13 11:31 Сейчас в теме
(28) При отключении по какой то причине сервера с журналом будет произведена попытка подключиться к журналу снова, если вторая попытка не удачная, то больше подсистема в данном сеансе не будет предпринимать попытки подключиться. После перезапуска сеанса все повторяется.
30. Dmitry Grabarev (dmitry-gr) 15.11.13 11:53 Сейчас в теме
(29) Diversus, не могли бы пояснить механизм кеширования соединения с базой. Что с ним будет если сеанс "переехал" на другой процесс или другой сервер?
31. Виталий Барилко (Diversus) 2213 15.11.13 12:32 Сейчас в теме
(26) Извините за не оперативный ответ (был на Infostart Event).

>> 1. Планируется ли возможность отката изменений ? - не самое важное.

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

>> 2. Планируется ли хранение самого первого состояния объекта, при его создании? У пользователей есть права на физическое удаление объектов, но иногда им злоупотребляют, и тогда данные можно было бы поднять из истории изменений, а не из бэкапа, как сейчас делаю.

Это есть. Хранятся все версии изменений.

>> 3. Планируется ли регистрация изменений в распределенных базах ? Ибо некоторые объекты меняются в разных перифериях, а в центре хотелось бы видеть консолидированную информацию по всем изменениям объекта. Это очень важный пункт, так как периферий много, и отслеживать изменения довольно таки трудно.

Да хотим сделать. Но тут сложность в том, что необходим механизм переноса данных из MS SQL из филиалов в центр. В MS SQL есть репликация данных (но в Expres если не путаю, этого нет). Либо какая нибудь выгрузка, либо еще что-то... Надо думать.

>> 4. Планируется ли возможность вести изменения нескольких 1С баз в одной внешней SQL?
Возможно в будущем. Т.к. по сути доработки для данного функционала минимальны.

Думали над этим, но в конце пришли вот к чему. Простой вопрос: а зачем? Проще, когда явно есть соответствие журнал бухгалтерии <-> бухгалтерия. Проще с переносом. Вдруг будет физический переезд одной базы на другой сервер. Когда журнал будет в одной базе, здесь будут сложности. Да и сжатие истории будет быстрее, если базы журналов физически различные.

>> 5. Через что идет работа с SQL сервером, будет ли подсистема работать под линуксом?

Через ADO. Под линуксом не могу сказать, не пробывал. Наверняка есть что нибудь, что заставит ADO работать из под линукса.
32. Виталий Барилко (Diversus) 2213 15.11.13 12:42 Сейчас в теме
(30) dmitry-gr, лучше расскажу про схему записи.

1) В конфигурации делается запись изменения объекта. Подписка на событие это изменение фиксирует и помещает его в кэш (специальный справочник в конфигурации) записывая полный образ объекта.
2) Фоновое задание обходит кэш и переносит все изменения объектов в журнал регистрации - БД MS SQL попутно "сжимая" изменения, находит какие реквизиты были изменены и переносит только их в журнал.
3) Из кэша удаляются обработанные записи.

Таким образом пользователь не имеет соединения с БД MS SQL. Это делает за него фоновое задание.
При запросе просмотре истории данные изменений получает так же сервер и возвращает на клиента таблицу с изменениями.
33. sanek sanek_gk (sanek_gk) 62 22.11.13 12:31 Сейчас в теме
Добрый день. Просветите пожалуйста. Чем ваша подсистема отличается по быстродействию от стандартной если стандартное версионирование хранит образы объектов в регистре сведений а вы свой кэш в справочнике. Чем обоснован выбор хранения кэша в справочнике?
34. Виталий Барилко (Diversus) 2213 22.11.13 12:46 Сейчас в теме
(33) sanek_gk, выбор справочника в качестве кэша обусловлен удобством дальнейшей обработки данных. По сути, на физическом уровне запись полного образа объекта занимает примерно одно и тоже время, что в справочник, что в регистр сведений.
35. helgi 19.12.13 18:44 Сейчас в теме
(34) Diversus,
В справочник быстрее, имхо, можно добиться, если в нем снести код/наименование, т.к. останется только кластерный индекс по ссылке, по которому дописываются данные в конец таблицы (не могут вставляться в середину). В регистре надо будет искусственный идентификатор, который сделать так, чтобы записи дописывались в конец без блокировки всей таблицы, невозможно.
36. Виталий Барилко (Diversus) 2213 19.12.13 18:51 Сейчас в теме
(35) helgi, если речь идет о постоянно очищаемом регистре и справочнике, где данные есть только до следующего регламентного задания, то скорость будет примерно одинаковая. Та разница о которой Вы говорите, для маленьких наборов данных не принципиальна.
37. helgi 19.12.13 19:07 Сейчас в теме
(36) Diversus,
да, согласен, не подумал, что у объем маленький.
38. Александр Кирилюк (ArtfulCrom) 15.01.14 06:31 Сейчас в теме
Я правильно понял, что каждое событие пишеться с клиента, а не с сервера?
Т.е. если клиенты не имеют доступа к одному скл серверу, то реализовать ваш журнал не возможно?

Например, в облаке?
39. Александр Кирилюк (ArtfulCrom) 15.01.14 06:35 Сейчас в теме
(38) извин-те, нашел ответ выше в каментах )))
40. Вячеслав (Borunmeert) 8 24.01.14 10:34 Сейчас в теме
Устанавливал все по инструкции, все норм кроме одного. Регламентное задание похоже не выполняется. База в три раза распухла, в логах стандартного журнала про фоновое задание это: {ОбщийМодуль.внОбщийМодуль.Модуль(853)}: Невозможно обработать параметр "ВестиИсториюИзменений" для получения значения. Что забыл сделать?
41. Виталий Барилко (Diversus) 2213 24.01.14 10:50 Сейчас в теме
42. Сергей Иванов (xten) 37 24.01.14 16:42 Сейчас в теме
Скажите, пожалуйста, купив Вашу программу Журнал Регистрации, к какому количеству баз (клиент-сервер) я могу ее подсоединить? Спасибо
43. Виталий Барилко (Diversus) 2213 24.01.14 16:57 Сейчас в теме
(42) В подсистеме нет проверки на количество подключаемых баз данных, поэтому, столько сколько захотите, но только в Вашей организации.
44. vik123 vik (vik123) 30.01.14 12:00 Сейчас в теме
Добрый день.
Планируется ли выпуск отчета по сравнению версий, аналогичного
отчету в разработке http://infostart.ru/public/71458/?
45. Виталий Барилко (Diversus) 2213 30.01.14 12:25 Сейчас в теме
(44) В планах, подобный отчет запланирован.
46. vik123 vik (vik123) 30.01.14 12:41 Сейчас в теме
(45) Diversus,
надо было сразу спросить))
а когда ожидать?
и еще вопрос, как отслеживаются изменения в табличных частях?
Допустим в доке удалили строку из середины тч.
Это будет регистрироваться как изменение всех последующих строк(сдвинулись на 1 вверх) или
как удаление конкретной строки?
47. Arikite (ArikiteSun) 25.02.14 12:02 Сейчас в теме
Можете дать доступ к демо версии?
48. Виталий Барилко (Diversus) 2213 25.02.14 12:15 Сейчас в теме
49. Сергей Иванов (xten) 37 19.03.14 13:46 Сейчас в теме
Скажите, пожалуйста, хотя бы примерно, на сколько процентов увеличивается скорость работы стандартной БП 2.0 ,15-20 одновременных пользователей (обычное приложение, MS SQL 2008)при использовании ЖурРег во внешней БД ?
Спасибо
50. Виталий Барилко (Diversus) 2213 19.03.14 14:08 Сейчас в теме
(49) Специальных замеров не делали, но при работе влияние не заметно. Пользователи ничего не почувствуют.
51. Вадим Окунев (Upiterus) 23.03.14 16:45 Сейчас в теме
Спасибо за журнал! Очень полезная вещь, всем рекомендую!:)

Единственное неудобство, с которым столкнулся при первичной настройке, - почему-то отсутствует в последнем релизе УТ 11.1.4.14 кнопка обновления справочника идентификаторов объектов метаданных. Танцы с изменением номера релиза и попыткой запустить стандартную обработку обновления ИБ ни к чему не привели:( Пришлось для этого выцарапывать из БСП обработку ИнструментыРазработчикаОбновлениеВспомогательныхДанных и используемые в БСП общие модули. Было бы неплохо для удобства пользователей добавить в обработку настройки журнала кнопу обновления идентификаторов.
52. Виталий Барилко (Diversus) 2213 24.03.14 10:00 Сейчас в теме
(51) Спасибо за отзыв, очень рад, что Вам понравилась наша разработка!
Насчет кнопочки для вызова БСП, сделал на сайте тикет для включения данного функционала в подсистему. Так что, ждите в следующем релизе.
53. Анна Зверева (Dirol-ka) 26.03.14 11:38 Сейчас в теме
добрый день.

есть ли демо версия?
54. Виталий Барилко (Diversus) 2213 26.03.14 11:42 Сейчас в теме
(53) Есть демо-сервер. В правом верхнем углу публикации кнопка "Показать демо".
55. pepe (pepe) 61 04.06.14 15:59 Сейчас в теме
Видел я этот продукт, очень сырой продукт и много не достатков в нем. Не рекомендую его использовать.
1) Не фиксировалась объекты у которых не изменялись реквизиты.
2) Чтобы регистрация велась нужно, чтобы у пользователя обязательно была установлена специальная роль
3) Возрастает нагрузка на сервер при сравнении, за счет этого система начала тормозить
4) Перенес базу на другой сервер, нужно помнить про настройки этого журнала
5) Если журнал изменений отключили, а у пользователя стоят роли журнала, то дальше выполняется большой кусок кода который не нужен.
6) Сам код написания очень запутанный и не всегда понятный.
Это только, что было на поверхности. Дальше не копал в нем.

56. Vit Red (lakra) 04.06.14 16:26 Сейчас в теме
используем на базе, в которой одновременно работает ~200 пользователей.
эксплуатируем 11 месяцев, проблем нет, тормозов нет, все довольны ибо каждый чих наглядно виден.
размер базы внешнего журнала регистрации ~950гигабайт.
57. Виталий Барилко (Diversus) 2213 04.06.14 17:12 Сейчас в теме
(55) pepe, зачем Вы пишите эту ерунду?
Подсистема на Инфостарте уже больше чем 1.5 года, имеет очень много клиентов, положительных отзывов.
Но я попытаюсь ответить на Ваше сообщение.
1) Не фиксировалась объекты у которых не изменялись реквизиты.

Как бы логично :) Зачем в журнале изменения, которые не изменялись? Т.е. открываем справочник нажимаем на кнопку ОК ничего не изменяя. Зачем в истории нам знать, что справочник не изменялся, а просто был перезаписан? Если нет изменений в объекте нет и записи в журнале. Как раз таки это позволяет убрать много не нужного хлама из журнала, чтобы вести действительно изменения по объектам, а не все подряд как в типовом журнале. Все логично.
2) Чтобы регистрация велась нужно, чтобы у пользователя обязательно была установлена специальная роль

Абсолютно верно. Дело в том, что для того, что бы пользоваться функциональностью подсистемы в системе 1С:Предприятия предусмотрено разграничение по правам, соответственно, если прав нет, то и функционал подсистемы использовать не получится. Далее есть два пути, добавлять роли для чтения и записи в уже существующие роли, либо добавить свои роли, который разрешат доступ к объектам. При первом подходе, если конфигурация типовая и будет обновлена в следующий раз, нам заново придется изменять права на наши объекты, поэтому логически верным и оправданным является введения собственных ролей, которые назначаются пользователям. При этом в подсистеме есть возможность в настройках установить права ВСЕМ быстро, щелчком одной кнопки. Без ролей ничего работать не будет и не только в нашей подсистеме. Вы даже константу добавите в конфигурацию, для пользователей без полных прав, она будет недоступной ни для чтения, ни для записи, а тут целая подсистема...
3) Возрастает нагрузка на сервер при сравнении, за счет этого система начала тормозить

"Навешивание" дополнительного функционала при записи и удалении объектов безусловно ведет к увеличению нагрузки. Но мы приняли все возможное, чтобы уменьшить ее. Например, была переработано сжатие объектов, оно осуществляется в фоновом задании (на обычных пользователей не влияет). Есть справочник кэша журнала регистрации, куда записываются не сжатые объекты.
Т.е. реализована связь:
СОБЫТИЕ ИЗМЕНЕНИЯ -> КЭШ ЖУРНАЛА РЕГИСТРАЦИИ -> ВНЕШНЯЯ СУБД MS SQL SERVER (в фоновом задании)
Разработана даже техника кэшированного считывания настроек для каждого пользователя (т.е. настройки подсистемы из БД считываются всего один раз для сеанса пользователя). И это только малая часть озвученных оптимизаций.
Такой подход позволяет существенно снизить нагрузку подсистемы.
Более того, комментарий (56) пользователя lakra говорит о том, что Ваше утверждение про сильное падение производительности голословно. ~200 юзеров в информационной базе работающих одновременно лучшее тому подтверждение.
4) Перенес базу на другой сервер, нужно помнить про настройки этого журнала

Все верно. Я Вам больше скажу, если Вы перенесете базу 1С на другой сервер, Вам придется переносить и типовой журнал регистрации. Да и к тому же, база не так часто переносится, чтобы бы говорить об этом серьезно.
К тому же, хранение информационной базы 1С и журнала регистрации отдельно друг от друга, дает свои плюсы, которые существенно выше, чем перенос основной базы на другой сервер раз в год.
5) Если журнал изменений отключили, а у пользователя стоят роли журнала, то дальше выполняется большой кусок кода который не нужен.

Абсолютная ложь! Вот пример кода, отрабатываемого при изменении объектов:
// Процедура фиксирует текущее состояние объекта и записывает в кэш
Процедура РегистрацияИзмененияОбъекта(Объект, НачальноеЗаполнение =  Ложь)
	
	// Журнал регистрации ведется?
	Если НЕ глВНЗначениеПеременной("ВестиИсториюИзменений") Тогда
		Возврат;
	КонецЕсли;
//...
...Показать Скрыть

По вашему этот код избыточен? :)
6) Сам код написания очень запутанный и не всегда понятный.

Вы не думали над тем, что если Вы не можете разобраться в коде, то может дело не в коде? :)

Все, что Вы написали абсолютно не соответствует действительности...
Пожалуйста, не вводите людей в заблуждение.
58. pepe (pepe) 61 06.06.14 18:57 Сейчас в теме
А теперь мои аргументы:
1) Документ не изменяли, а просто перепровели. Проводки по партиям изменились, а в журнале нам не показывает изменений, как то не очень хорошо.
2) На счет ролей понятно, но лучше чтобы была привязка к роли "Пользователей", при добавлении пользователей, очень часто не ставят данную роль.
3) Очень странно, что при 200 пользователях система работает стабильно. Фоновое задание памяти кушает не много, а вот процессор и время выполнения не радует.
По оптимизации:
Почему параметры работы не вынесены в модуль Повторного использования, для ускорения работы, как в типовых решениях. Это сильно увеличивает производительность. Также использование ХранилищеЗначения очень замедляет работу. Провел тестирование механизма: записывал 100 элементов справочника банковские счета. С включенным алгоритмом 8 с, без него и с версионирование 5 с. Для чистоты эксперимента запуска замер 10 раз, показатель средний.
4) Типовое Версионирование работает в любом случаи.
5) Код с подписки на событие при записи регистра сведений:
Если НЕ РольДоступна("внПользовательИсторииИзменений") И НЕ РольДоступна("внАдминистраторЖурналаРегистрации") И НЕ РольДоступна("внПросмотрЖурналаРегистрации") Тогда
Возврат;
КонецЕсли;


Если Источник.ОбменДанными.Загрузка И НЕ глВНЗначениеПеременной("ФиксироватьИзмененияПриОбменеДанными") Тогда
Возврат;
КонецЕсли;

// Добавляем дополнительные свойства
Если НЕ Отказ Тогда
ПолноеИмя = Источник.Метаданные().ПолноеИмя();
Запрос = Новый Запрос;
СписокПолейУсловияОтбораТекст = "";
Для каждого ЭлементОтбора Из Источник.Отбор Цикл
Если НЕ ЭлементОтбора.Использование Тогда
Продолжить;
КонецЕсли;
Если НЕ ПустаяСтрока(СписокПолейУсловияОтбораТекст) Тогда
СписокПолейУсловияОтбораТекст = СписокПолейУсловияОтбораТекст + " И ";
КонецЕсли;
СписокПолейУсловияОтбораТекст = СписокПолейУсловияОтбораТекст +" Набор." + ЭлементОтбора.Имя + " = &" + ЭлементОтбора.Имя;
Запрос.УстановитьПараметр(ЭлементОтбора.Имя, ЭлементОтбора.Значение);
КонецЦикла;

Если НЕ ПустаяСтрока(СписокПолейУсловияОтбораТекст) Тогда
СписокПолейУсловияОтбораТекст = " ГДЕ " + СписокПолейУсловияОтбораТекст;
КонецЕсли;

Запрос.Текст =
"ВЫБРАТЬ * ИЗ " + ПолноеИмя + " КАК Набор
| " + СписокПолейУсловияОтбораТекст;
ТЗРегистра = Запрос.Выполнить().Выгрузить();

Источник.ДополнительныеСвойства.Вставить("внРегистрСведенийЗаписью", ТЗРегистра);
КонецЕсли;

Я как то не вижу проверку глВНЗначениеПеременной("ВестиИсториюИзменений").
Возможно у меня конфигурация старая, но думаю это мало вероятно.
6) Каждый воспринимает по своему.
59. Виталий Барилко (Diversus) 2213 06.06.14 19:29 Сейчас в теме
(58) pepe,
1) Документ не изменяли, а просто перепровели. Проводки по партиям изменились, а в журнале нам не показывает изменений, как то не очень хорошо.

Подсистема показывает изменения. В документе по факту ничего не изменилось.
2) На счет ролей понятно, но лучше чтобы была привязка к роли "Пользователей", при добавлении пользователей, очень часто не ставят данную роль.

В типовых конфигурациях на УФ с использованием БСП, сейчас это все решается на уровне профилей прав. Создал один раз профиль внеся туда нашу роль, потом включаешь пользователям нужный профиль и все. С профилями настроил и забыл.
3) Очень странно, что при 200 пользователях система работает стабильно. Фоновое задание памяти кушает не много, а вот процессор и время выполнения не радует.
По оптимизации:
Почему параметры работы не вынесены в модуль Повторного использования, для ускорения работы, как в типовых решениях. Это сильно увеличивает производительность. Также использование ХранилищеЗначения очень замедляет работу. Провел тестирование механизма: записывал 100 элементов справочника банковские счета. С включенным алгоритмом 8 с, без него и с версионирование 5 с. Для чистоты эксперимента запуска замер 10 раз, показатель средний.

Прототип подсистемы родился еще в 8.1 и по идее все настройки хранятся в параметре сеанса и скорость должна быть сопоставима с использованием модуля с повторным использованием значений. Надо будет сделать замеры. Если окажется, что скорость на порядок выше, изменим, не проблема.
4) Типовое Версионирование работает в любом случаи.

Начали говорить про минусы нашей подсистемы, говорите и про минусы версионирования.
Минусы версионирования:
1) серьезное увеличение размеров БД, что влечет за собой замедление обновления и реструктуризации данных.
2) невозможность быстрой выгрузки и потом загрузки базы в тестовую, т.к. объемы неприлично большие.
3) информационная база 1С становится не транспорабельной, если в ней работает очень много пользователей. Только перенос средствами СУБД. Штатной выгрузкой будет работать очень долго.
Мы через все это проходили, поэтому остановились на отдельном хранении истории журнала вне информационной базы 1С.
5) Код с подписки на событие при записи регистра сведений: Возможно у меня конфигурация старая, но думаю это мало вероятно.

Да. Это старая версия подсистемы.

В целом, я позитивно оцениваю критику, но только конструктивную...
Если у пользователей подсистемы есть вопросы или предложения по улучшению функционала, они пишут о них нам в тикет-системе на нашем сайте, мы стараемся их решить и угодить всем. Вам, тоже надо было так сделать.
60. Андрей Старченко (dr.death) 42 25.06.14 06:30 Сейчас в теме
Сплошной обман! Покупали версию 1.0.4.1 Установил. Косяков куча, вплоть до того что записи ЖР просто не переносились (архивировались) в SQl, т.е. срабатывало регламентное задание и висело!!! Потом вышло обновление 1.0.5.5 И ТОЖЕ САМОЕ + тормозить чуть чуть меньше стало. База росла примерно на 2 Gb в день!!! При этом наблюдалось заметное снижение производительность, планировал подключать к двум базам, в итоге пришлось отказаться от использования на первой. Об этом всё писал в тех поддержку, в итоге включили пару ошибок к исправлению в будущих версиях. В ИТОГЕ ВЫШЛА ВЕРСИЯ 2 И ОБНОВЛЕНИЯ НЕ МОГУ СКАЧАТЬ, ПИШУТ КУПИТЕ ЗА 3000 руб. Как понимать?!!!!! Если вы обновляете свои косяки ( обратите внимание что программа была до этого приобретена), то доводите их до логического завершения, а вы выпустили новую версию и просите денег. не хорошо... да и где гарантия что опять не опрокинете... вообщем впечатления резко негативные!
61. Виталий Барилко (Diversus) 2213 25.06.14 12:51 Сейчас в теме
(60) dr.death, согласно условиям лицензионного договора обновления предоставлялись бесплатно для версий 1.x.x.x. Сейчас вышла версия 2.0.0.0, начиная с этой версии обновления предоставляется по подписке. Поэтому мы никого не обманываем. Более того, для пользователей, которые приобрели подсистему после 01.04.14 мы предоставили бонус в виде бесплатной полугодовой подписки.
Теперь о проблемах.
База росла примерно на 2 Gb в день!!!

Почитайте инструкцию по работе с подсистемой, там есть такая тема: "Что делать если очень быстро растет база данных журнала в MS SQL". Там же рекомендации по настройке MS SQL, а так же по настройке самой подсистемы, чтобы и производительность и размер журнала были оптимальными.
При этом наблюдалось заметное снижение производительности

Снижение производительности не должно так сильно сказаться на работе конфигурации. Среди наших клиентов есть организации с ~200 пользователями в онлайн, где подсистему используют уже около года и размер БД 950 Гб. Они довольны и производительность их вполне устраивает. В вашем случае необходим более детальный анализ.

Теперь по поводу обращений в техподдержку. Проверили от Вас было зарегистрирован только один тикет, который не касался работы регламентного задания и который был решен.
Если действительно есть проблемы, на которые мы вовремя не отреагировали, напишите нам на почту, если это действительно наша вина и мы ее не решили, вопрос будет решен в вашу пользу.
62. Виталий Барилко (Diversus) 2213 10.07.14 12:45 Сейчас в теме
26.06.14 Версия 2.0.0.3

[*] Проверка уникальности информационной базы объединена с проверкой необходимости ведения истории.
[!] Исправлена ошибка чтения наличия пользователей в конфигурации.
63. Марина Семёнова (SemenovaMarinaV) 30.07.14 14:27 Сейчас в теме
А не будет ли внешяя база по размеру в несколько раз больше основной?
64. Виталий Барилко (Diversus) 2213 30.07.14 14:46 Сейчас в теме
(63) SemenovaMarinaV, во внешней базе хранятся изменения объектов.
Если документ записали, его реквизиты, табличные части переносятся полностью, потом при изменении этого документа будут записываться только его ИЗМЕНЕНИЯ. Т.е. изменили один реквизит, будет записан только один реквизит и т.д.

Т.е. безусловно данные БД журнала могут достигать большого размера, сопоставимого с размером основной базы, но они не будут влиять на работу основной базы, т.к. находятся вне ее и поэтому переживать не стоит.

Плюс, мы добавили в версии 2.0 функционал по очистке устаревших данных, а это позволит удалять старые и уже не нужные данные. Об этом подробнее, так же в документации.
65. pepe (pepe) 61 07.08.14 16:21 Сейчас в теме
В новой обработке по описанию, уже улучшили некоторые механизмы на которые не нравились мне и идея хорошая с единым журналом для всех баз УРБД, осталось посмотреть на реализацию и работоспособность.
66. Виталий Барилко (Diversus) 2213 11.08.14 09:22 Сейчас в теме
(65) pepe,

В версии 2.0.1 добавляем поддержку распределенных баз данных. Реализовали 2 вида обмена:
1) Полный. Это когда правится план обмена и происходит помимо обмена основными данными, обмен данными журнала.
2) Упрощенный. Когда фиксируется при обмене только база-источник из которой грузятся изменения.
Каждый из типов имеет свои плюсы и минусы, которые будут отражены в справке.

Версия 2.0.1 выйдет в ближайшее время.
67. Юрий Липовский (Юрий ЛЛ) 19.08.14 11:48 Сейчас в теме
поддержка и обновления платные на эту прогу?
68. Виталий Барилко (Diversus) 2213 19.08.14 12:08 Сейчас в теме
(67) После покупки первые полгода бесплатно, потом за отдельную плату (1 год - 3500 р.)
Обновления предоставляются по принципу ИТС.
69. Юрий Липовский (Юрий ЛЛ) 19.08.14 12:42 Сейчас в теме
почему нигде не написано про это?(68) Diversus,
70. Виталий Барилко (Diversus) 2213 19.08.14 12:55 Сейчас в теме
(69) Юрий ЛЛ, написано в разделе "Вопрос-ответ":
Вопрос: Будет ли система и дальше развиваться и обновляться?
Ответ: Конечно! Подсистема постоянно развивается и обрастает новым функционалом. После покупки в качестве бонуса первые полгода обновления предоставляются бесплатно.
71. Юрий Липовский (Юрий ЛЛ) 19.08.14 15:18 Сейчас в теме
(70) Diversus, Хорошо, есть Юрий ЛЛ, который уже сталкивался с твоими программами
и необъявленными(скрытыми) ценами на обновления.
Зато теперь ты можешь ссылаться на твой ответ мне, если кто-то задаст такой же вопрос как и я.
Так и напишешь - "Ну вот же я в комментариях писал цену..."
72. Виталий Барилко (Diversus) 2213 19.08.14 21:20 Сейчас в теме
(71) Юрий ЛЛ, спасибо! Обновил публикацию и ввел в разделе вопрос-ответ пункт, касаемо обновлений и поддержки, а так же их стоимости.
73. Алексей Роза (DoctorRoza) 10.11.14 08:15 Сейчас в теме
Предложу своему директору! Разработка достойная! :)
74. Игорь Дзеса (Kamikadze) 44 26.11.14 16:11 Сейчас в теме
Diversus, аргументы pepe серйозные. Зачем система, где не фиксируется проведение документа? Это же влияет на суть данных, которые хранятся в базе 1С. И то, что такой вариант не отслеживается - очень плохо. в основном из-за этих проблем и смотрят все в журнал регистрации от 1С-ки. Я вот думал приобрести, но.... это НО меня останавливает.
tramontana; +1 Ответить 2
75. Виталий Барилко (Diversus) 2213 26.11.14 17:02 Сейчас в теме
(74) Kamikadze, событие фиксируется если есть ХОТЯ бы одно изменение в объекте.
Если изменений в объекте нет, то объект не изменился, а так как нам важна именно фиксация изменений, то мы это не записываем.
Технически реализовать запись документа только при перепроведении не сложно, но нужно ли это?
Хотя мы такую возможно можем добавить опционально и исключительно для документов... Типа, если пользователь нажал на кнопку ОК в документе и при этом ничего не поменялось в документе, то фиксировать событие перепроведения документа.
76. Виталий Барилко (Diversus) 2213 26.11.14 17:08 Сейчас в теме
(74) Тут просто вся соль в том, что если пользователь открыл документ и просто нажал на кнопку ОК. То при анализе образа объекта получается, что как будто ничего не изменилось.
Хотя, конечно, простое перепроведение документа, особенно при партионном учете может навести "шороху" в информационной базе.
Мы, все таки наверное, подумаем над реализацией и добавим это опционально, фиксировать такие событие в истории или нет.
77. Вадим Мананников (manan) 26.11.14 20:46 Сейчас в теме
Почему в качестве хранилища изменений не используется отдельная база 1с?
78. Виталий Барилко (Diversus) 2213 26.11.14 21:38 Сейчас в теме
(77) manan. Как говорится, так исторически сложилось :)
Но самое забавное, что в версии 2.0 мы заложили возможность расширения поддерживаемых СУБД для хранения журналов изменений и мысли добавить отдельную базу 1С для хранения журналов были.
79. Игорь Дзеса (Kamikadze) 44 27.11.14 12:07 Сейчас в теме
(75) Diversus, я бы иначе сформулировал - если были изменения в регистрах при проведении, то это нужно фиксировать. Это пожелание, которое, как мне кажется, очень нужное в работе пользователя. Хотя ваш вариант более предпочтителен.

(76) Diversus, хорошо :)
80. Игорь Дзеса (Kamikadze) 44 27.11.14 12:08 Сейчас в теме
(78) Diversus, есть ли задумка реализации хранения данных на не реляционной базе данных, где поиск будет существенно быстрее?
81. Вадим Мананников (manan) 09.12.14 10:27 Сейчас в теме
Хочу приобрести на организацию, с возможностью дорабатывать. Код конфигурации полностью открыт?
82. Алекс Ю (AlexO) 113 10.12.14 11:22 Сейчас в теме
(81) manan,
Код конфигурации полностью открыт?

С чего бы, если даже обновления - платные?
83. Виталий Барилко (Diversus) 2213 10.12.14 12:15 Сейчас в теме
(82) AlexO, код подсистемы полностью открыт.
Мы работаем над подсистемой и периодически выпускаем обновления к ней.
Появилась очередная хотелка, нашли ошибку, вышла 8.3 без использования режима модальности и т.д. мы доработали/исправили.
Дали скачать пользователям.
Если подписка заканчивается то, обновления не предоставляются, но тем не менее код полностью открыт.
Продлили поддержку - получили последнюю актуальную версию и никаких проблем.
84. tixis1c tixis1c (qwed557) 26 10.12.14 13:00 Сейчас в теме
(56) lakra, за 11 месяцев 950 Гб??? Ну и аппетиты.
85. Виталий Барилко (Diversus) 2213 10.12.14 13:49 Сейчас в теме
(84) Ничего удивительного в таком размере нет.
Представьте, фиксируются ВСЕ изменения объектов. Т.е. зашли в документ заполнили, сохранили и провели. Потом открыли, изменили один реквизит, или пару, перепровели и т.д. Естественно в ИБ 1С объект как был один так и остался, а в журнал попадают сразу все изменения объекта, после каждой записи и неважно, что следующие шаги - только изменения объекта. Все равно много данных записывается. И это только для одного документа.
А когда в ИБ 1С 150 пользователей в онлайне и каждый что-то делает, то данные журнала растут.
Так что, повторюсь, ничего удивительного нет.
86. Алекс Ю (AlexO) 113 11.12.14 11:35 Сейчас в теме
(85) предстаьте, вы б в 1С реализовали такое версионирование хранить...
Хотя все равно много - ну гигов 50-60 за 11 месяцев - нормально. Там что за формат хранения? Может, пустоты много "хранится"?
87. Вадим Мананников (manan) 11.12.14 14:24 Сейчас в теме
Приобрел конфигурацию. При попытке сделать первоначальное заполнение (кстати, зачем оно вообще нужно) сразу ошибка:
{ОбщийМодуль.внОбщийМодуль.Модуль(1492)}: Ошибка при вызове метода контекста (Выполнить)
Результат = Запрос.Выполнить();
по причине:
{(4, 2)}: Таблица не найдена "РегистрСведений.РегистрСведенийСРегистратором"
<<?>>РегистрСведений.РегистрСведенийСРегистратором КАК Регистр

Впечатление испорчено. Как бороться с ошибкой, подскажете?
88. Виталий Барилко (Diversus) 2213 11.12.14 14:28 Сейчас в теме
(87) manan, пишите нам на почту, или в скайп, мы реагируем быстро.
Если что подключимся по TeamViewer поможем.
89. Виталий Барилко (Diversus) 2213 11.12.14 14:41 Сейчас в теме
90. Вадим Мананников (manan) 11.12.14 15:05 Сейчас в теме
(88) Первоначальное заполнение не удалось выполнить, ошибка - "Недостаточно памяти". Как-то все печально. Если очевидно, что при первоначальном заполнении будет обрабатываться большое количество данных, логично было бы эту процедуру как-то более оптимально реализовать.
91. Павел Белан (webcisp) 18.01.15 03:32 Сейчас в теме
У нас базы 1С "крутятся" на сервере PostgreSQL (Linux) - ваше решение будет с нашими базами работать ?
92. Виталий Барилко (Diversus) 2213 18.01.15 22:14 Сейчас в теме
(91) webcisp, к сожалению пока все работает только в связке Информационная база (ИБ) + Windows + MS SQL (для журнала). Но мы планируем в будущем добавить: ИБ + Windows + 1C (для журнала), возможно так же добавим и ИБ + Linux + 1C (для журнала).
93. Алекс Ю (AlexO) 113 19.01.15 10:33 Сейчас в теме
(91) webcisp,
на сервере PostgreSQL (Linux) - ваше решение будет с нашими базами работать ?
Если фраза в названии темы "во внешней БД MS SQL Server" ни о чем не говорит, то вам лучше не подключать пока ничего вообще))
94. Зоя Сорокина (Soikalv) 22.01.15 12:20 Сейчас в теме
Очень неудобно. что фиксируются именно любые изменения объекта. Журнал становится слишком громоздким. Нужна или нет информация. кто вообще открывал документ в текущем режиме - это вопрос. Мне кажется. было бы логичнее фиксировать в журнале только те события. которые привели к изменению каких-либо реквизитов объекта. Или настроить функцию вабора реквизитов, которые будут выводиться в журнале.
95. Виталий Барилко (Diversus) 2213 22.01.15 12:24 Сейчас в теме
(94) Soikalv, так журнал так и работает. Фиксируется только то, что изменилось у объектов. Открытия документов не фиксируются.
Есть так же возможность настройки фиксации изменений и указать те объекты и реквизиты, которые нужны в истории.
96. Namig Pirkuleiv (Namig) 22.01.15 18:47 Сейчас в теме
можно ли похожее делать для 8'018'2? только с урезанными функциями.
97. Виталий Барилко (Diversus) 2213 23.01.15 09:07 Сейчас в теме
(96) Namig, подсистема работает в 1С версий 8.2 и 8.3, более ранние нет смысла поддерживать, т.к.
1) 95% пользователей 1C v8 работают именно на этих версиях
2) 8.0 и 8.1 - устаревшие версии и нет смысла делать, что-то для старых платформ ввиду сокращения пользователей.
98. Вадим Мананников (manan) 03.02.15 11:38 Сейчас в теме
Итак, крайне неприятное наблюдение при работе с системой.
Зачем сделано назначение роли внПользовательИсторииИзменений юзерам опционально, если это не работает? Конечно, удобно было бы отключить например логирование администраторов, НО! Будем иметь неправильную информацию об изменениях.
Пример: есть пользователь Админ (которого не хотим логировать) без роли внПользовательИсторииИзменений и пользователь Юзер с ролью внПользовательИсторииИзменений.Включаем логирование реквизита "Руководитель" справочника "Сотрудники". Дальше:
1. Пользователь Юзер меняет руководителя какого-либо сотрудника с Иванов на Петров.
2. Пользователь Админ меняет руководителя того же сотрудника с Петров на Сидоров
3. Пользователь Юзер меняет руководителя того же сотрудника с Сидоров на Козлов.
Внимание, вопрос: что вы ожидаете увидеть в журнале регистрации для пункта 3? Лично я (логично) следующее: руководитель сотрудника был изменен пользователем Юзер с Сидоров на Козлов. НО! Разработчики конфигурации (нелогично) считают так: руководитель сотрудника был изменен пользователем Юзер с Петров на Козлов. Загадка, блин!
Надеюсь, авторы системы не будут отмалчиваться здесь, посылая таких вот добросовестных приобретателей их поделки как я в почту/скайп/личку, а заявят во всеуслышание, что да, имеются крупные косяки в нашей недешевой поделке, исправлять будем/не будем (нужное подчеркнуть).
99. Виталий Барилко (Diversus) 2213 03.02.15 13:26 Сейчас в теме
(98) manan,

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

По поводу выделенной роли нужна она или нет. Тут вот в чем дело. Некоторые пользователи просили, чтобы у журнала была возможность исключения некоторых пользователей из журнала на некоторое время. Это нужно было для обменов, по которым необходимо сделать массовую загрузку, или массовое изменение объектов определенного типа, или экстренно сделать загрузку большого числа объектов в базу. И чтобы это сделать быстрее, если объектов очень много, убирают у себя роль, перезапускают конфигурацию и производят в базе определенные действия, чтобы массовые изменения данных, не так долго грузились, при этом сознательно допуская, что именно их изменения не будут учтены журналом. Поэтому родился именно такой подход. Вам он не удобен, но некоторые просили сделать такую возможность.

Верно ли это с методологической точки зрения? Наверное все же нет... Так как, действительно, теряется правильная последовательность изменений в журнале, но мы сознательно пошли на это, чтобы это было именно опционально как описано выше. Нам прекрасно известно как работает блок:
УстановитьПривелегировнныйРежим(Истина);
//...
УстановитьПривелегировнныйРежим(Ложь);
И что привелегированным режимом можно было избавиться от этой лишней роли, для записи в тот же кэш изменений пользователем...

Теперь по поводу отписок в скайп/личку/team viewer и т.п. О чем Вы написали.
Я считаю хорошей практикой, когда с чем-то озадаченным пользователем, пытаются связаться на прямую и выяснить более подробнее об ошибке или пожелании. Мне кажется наоборот так пользователь получает обратный отклик и точно не останется один на один с проблемой, если она у него возникла. Вы неверно приняли заботу о конечном пользователе, попыткой скрыть ошибки в подсистеме. Ошибки есть везде и это, всем известный факт. Пишите на ящик поддержки, мы отвечаем и если действительно ошибка, мы включаем ее в баг-треккер и работаем по ней и к следующему релизу стараемся, чтобы все были довольны. Но то, что Вы указали выше - это не баг, это, сознательный шаг. Если все делать по инструкции и всем проставить роль, все будет работать как надо...

Спасибо.
100. Вадим Мананников (manan) 06.02.15 09:08 Сейчас в теме
(99) Коллеги, ну реально уже не смешно. Я ожидал с помощью Вашей разработки решить конкретную проблему, а именно - выловить человека, который меняет руководителя сотрудника. Сначала выставил период журнала месяц, в итоге журнал даже не открылся - все повисло. Потом поставил - неделю, форма журнала открывается, но пустая и неактивная - видимо идет заполнение. С трудом форма все же заполнилась, но неактивна по-прежнему. В общем, тормоза еще круче, чем в штатном журнале регистрации от 1С. И это я включил только логирование одного реквизита одного справочника плюс еще регистрацию фактов перепроведения документов. Регламентное задание "Обработка журнала регистрации" вообще не успевает отработать за 10 минут. Есть возможность вернуть деньги через Инфостарт? Сильно жалею что приобрел. Наверное, версионирование из БСП лучше прикрутить.
101. Виталий Барилко (Diversus) 2213 06.02.15 11:00 Сейчас в теме
(100) Звонил на ваш номер, но вы не взяли трубку...
Связался с дирекцией Инфостарта, совместно решили вам сделать возврат и тут дело не в том, что разработка плохая, а в том, что автор поста (100) уже хорошо известен Инфостарту с не очень хорошей стороны, как проблемный и склочный человек... Так что для таких как вы, ей богу, сделать возврат проще, чем иметь такого клиента у себя.

Теперь по тексту.
Не знаю с какой целью, но Вы сознательно и не обоснованно вводите людей в заблуждение.
1) Если включена регистрация только одного справочника и одного реквизита в этом справочнике + перепроведения документов, то Вы явно лукавите. Не может быть столько изменений этого одного реквизита, чтобы журнал долго открывался и долго сжимался. Выше отписывались люди у которых все прекрасно отрабатывало и журнал был больше ~950 Гб и все нормально работает. А у Вас тут, понимаешь, один реквизит в одном справочнике регистрируется и журнал не открывается...
2) С тем, что версионирование из БСП лучше - это тоже лукавство, чистой воды. К нам обычно обращаются, как раз уже тогда, когда попробуют использовать версионирование и через неделю база распухает до невероятных размеров и они принимают решение не использовать этот механизм и ищут ему замену.

PS: Я очень ревностно отношусь к своим коммерческим решениям, за более чем 4 года успешного сотрудничества с Инфостартом (!) не было НИ ОДНОГО такого клиента с такими претензиями как вы! Доржи не даст соврать. Говорите о проблемах, но на прямую не обращаетесь с ними ко мне, мои просьбы связаться через skype и показать проблемы через Team Viewer игнорируете и при этом откровенно обманываете как в п.1. Так что не надо троллить и очернять ни меня ни разработку, я приложил максимум усилий и терпения!

Итак, возврат Инфостарт сделает, соответственно неадекватные претензии ко мне с Вашей стороны автоматически снимаются, так что не утруждаетесь отписками в этой теме, я Вам более ничего не должен...

Для остальных:
Вообще конечно, мое упущение, что я не сделал табличку с плюсами и минусами, замерами производительности типового журнала, версионирования и нашего журнала на MS SQL. Обещаю в ближайшее время постараюсь это сделать, чтобы все, что изложено выше уже не могло бы недобросовестными людьми использоваться как аргумент.
v.a.ryag; JesteR; rayastar; klinval; kalevra67; vadimlp77; denis_aka_wolf; Rokstedi; Uncore; tiniji; xMen; kuzyara; Alex George; support; +14 Ответить 1
103. Сергей Клабуков (klabuk0v) 12.02.15 09:07 Сейчас в теме
А есть возможность взять систему на тестовый период? 30 дней например. Поставить систему, сделать замеры и только потом принять решение о покупке?
104. Виталий Барилко (Diversus) 2213 12.02.15 09:08 Сейчас в теме
(103) Как я обещал, выложу результаты тестирования системы в публикацию чуть позже, самостоятельно.
105. Виталий Барилко (Diversus) 2213 25.02.15 17:51 Сейчас в теме
Обновление от 19.02.15 Версия 2.0.3.6
[!] Исправлена ошибка, которая могла возникать при сжатии кэша журнала регистрации на больших объемах данных. Изменен механизм получения данных при сжатии.
106. Олег Познянский (olegpoz) 19.03.15 12:35 Сейчас в теме
Добрый день!
Пока только знакомлюсь с вашим продуктом - очень похоже что он нам понравится)

Однако - почему нельзя было бы поменять логику с ролью "(ВН) Пользователь журнала регистрации" ?
Понятно что для НЕКТОРЫХ пользователей, иногда нужно отключать регистрацию.
Почему не сделать по-умолчанию - для всех регистрируем, а при включенной роли "(ВН) Не регистрировать..." - не регистрируем ??

Не пришлось бы для каждого новго юзера следить за этой ролью (а с БСП еще и за группой доступа)
Или я не прав?