(4) higs,
Я как раз начал с обратного - сначала обработка с уже возможным некоторым применением, а затем уж описал формат по тому что получилось в обработке.
А применение знаний формата пока основное вижу только одно - если есть понимание формата, то можно лечить некоторые виды повреждений журнала регистрации 1С 8.
Так же на Инфостарте уже есть несколько разработок, которые что-то делают с журналом регистрации, возможно им пригодится перевод на прямое чтение файлов.
если есть понимание формата, то можно лечить некоторые виды повреждений журнала регистрации 1С 8.
тогда ждем через неделю обработку "Как и где лечить поврежедния журнала".
С сопроводительной статьей "Повреждения журнала и причины этого".
Можно еще приложение - "Виды повреждений на примерах". ;)
тогда ждем через неделю обработку "Как и где лечить поврежедния журнала".
С сопроводительной статьей "Повреждения журнала и причины этого".
Можно еще приложение - "Виды повреждений на примерах". ;)
Чтобы что-то лечить, нужно видеть больного. Что-то желающих делиться проблемными журналами пока нет, а в своих архивах пока не наткнулся на проблемы.
Часто возникает проблема "Недостаточно памяти" при чтение журнала, так тут и лечить собственно нечего, нужно прочистить журнал от ненужных событий (планируется в будущих версиях обработки) или переходить на хранение копий журнала для анализа в сторонней базе.
Поставил "+" за детальность и объем проделанной работы.
А какой смысл считывать 1С-ом данные из журнала регистрации 1С ?
Я как-то могу понять, когда данные считываются внешним приложением, отличным от 1С.
В 1С есть свое представление журнала регистрации с возможностью отбора. Где можна
использовать полученные знания на практике ?
Журнал регистрации можно использовать для анализа изменений в базе, и выгрузки этих данных в другую ис за определенный промежуток. Это альтернатива плану обмена, но более универсальная. Плюсанул за труды.
Выяснил еще пару подробностей про журнал регистрации 1С 8.2
1) Разбивать запись на дополнительный строки необязательно, т.е. файл будет вполне читаться платформой через Файл - Открыть даже если не соблюдать правила по поводу фигурных скобок и связанных с ними переводов строк
2) Пока по моим наблюдениям в последнем элементе записей файла данных всегда содержится "{0}". Возможно это маркер окончания записи.
Просьба к тем, кто обнаружит обратное сообщить об этом здесь.
Мир этому дому!
В очередной раз убеждаюсь, что в сообществе много людей, которые разобравшись в вопросе или проблеме, готовы поделиться своими результатами. Спасибо за ценную информацию.
После долгих попыток понять почему при делении файлов журнала регистрации транзакции помечаются как незавершенные пришел к выводу, что умозаключение
"3) Транзакция в формате записи из двух элементов преобразованных в шестнадцатеричное число – первый – число секунд с 01.01.0001 00:00:00 умноженное на 10000, второй – номер транзакции"
оказалось неверным. Второй параметр это не номер транзакции, а смещение в файле данных журнала регистрации по которому начинается первая запись по этой транзакции.
(14) благодарю за наводку: помогла инфа касательно смещения. Переписал свою обработку, основанную во многой на вашей, по перекодировке файла журнала данных и теперь транзакции с правильными статусами отображаются.
(24) Добрый день! Не могли бы вы поделиться алгоритмом расчета смещения для транзакции? Тоже наткнулся на данную проблему, что транзакции помечаются, как незавершенные
(0) Плюс Вам, конечно, за работу, но статья больше носит характер "академической".
Типовой журнал это неудобная вещь, медленная и не информативная.
Я пошел другим путем и не стал опираться на типовой журнал а сделал свою подсистему
Так случилось, что был утерян файл словаря. Решил схитрить и подсунуть 1С файл словаря от той же базы, но с выгрузкой за другую дату. Оказалось, что файл словаря был создан заново и порядок идентификаторов в нем другой, не то что по метаданным, но даже по событиям. <сарказм> Удивительно! </сарказм>
Сейчас думаю, что делать. Больше всего похоже на то, что восстановить словарь без непотребных трудозатрат не выйдет.
Не подскажите, почему в 8.2 в журнал регистрации не записываются блокировки по таймауту и взаимоблокировки, возникающие при записи / проведении документов. В 8.1 вроде бы они туда попадали. А в 8.2 сообщение пользователю выводится, но в журнал не записывается. "Попыток" нет.
Спасибо. Информативно. У меня вопрос следующего характера - можете по подробнее описать что означают или в каких ситуациях возникают все из перечисленных статусов транзакции?
И кстати журналы в базах в которых пользователи сидят не читаются, думаю нужно было сделать чтение через VBScript - там вроде заблокированные на запись файлы читаются
Не заметил информации относительно того, как выбрать журнал регистрации нужной базы. В директории "C:\Program Files\1cv8\srvinfo\reg_1541" лежит куча ГУИДОВ и файл "1CV8Clst.lst". Вот в нем-то и хранятся сопоставления.
Так же встречаются пока неопознанные коды 11, 12 и 13
Я сейчас работаю над переводом старой версии журнала на Sqlite (конвертация файлов) и вроде как докопался до 11,12 и 13 кодов. Они имеют чуть иную логику, нежели предыдущие. И их суть сводится к таблице ComputerToUserCodes на sqlite. А именно, связи компьютеров и пользователей, которые с них заходили. Причем 13й может идти несколько раз подряд. Вместо значения и индекса тут связь индекс-индекс.
Похоже, что 11й добавляется после пользователя и означает начало блока связки этого пользователя с компьютером. 12й после добавления компьютера и символизирует начало связки с пользователем. А 13е - это непосредственно сами данные, как "связать".
13й не происходит при выполнении фонового задания. То есть 13й массив заполняется лишь связями клиентских пользователей и машин
Также есть подозрения, что 11й и 12й не влияют а 13й. Похоже, они задумывались, как вспомогательные массивы под пользователей и машины. Но на практике у них всегда заполнен {0} в качестве значения. С точки зрения анализа и переноса в новый формат, это бессмысленная информация. Рудимент и не более.
Тоже очень (просто жизненно) интересно что означает {"P",{6,{"S","Строка1"},{"S","Строка2"}}}
Столкнулся с проблемой обращения к журналу регистрации через SQLite. Приходится расшифровывать все эти данные для вывода в табличную часть и последующего отбора. Для указанной комбинации перепробовал все возможные типы. Ничего не подошло.
Может кто разобрался что это за данные?
Код 13 в lgf-файле - это аналог записи таблицы ComputerToUserCodes в журнале lgd. Где в нулевом элементе массива код вида элемента, в 1м - код компьютера, а во 2м - код пользователя.
2) Статус транзакции – может принимать четыре значения "N" – "Отсутствует", "U" – "Не завершена" и "C" – "Зафиксирована", "R" – "Отменена";
и размер кода транзакции больше
Не нашел в статье информацию по кодам 9 и 10 из файла описания ЖР.
{9,530a3164-4ef1-4b3b-8269-13764ef4bf15,"ОбластьДанныхВспомогательныеДанные",1}
судя по этой записи, код - это общий реквизит (конфигурация работает в модели сервиса, т.е. используется режим разделения данных)
А вот строка с кодом 10 может выглядеть следующим образом:
{10,
{"N",33738},1,10},
{10,
{"N",33738},2,10},
Заметил, что они идут в паре, как указано выше. Предполагаю, что это может быть информация по области данных, т.к. изначально строка с кодом 10 появилась вместе со строкой с кодом 9
{9,530a3164-4ef1-4b3b-8269-13764ef4bf15,"ОбластьДанныхВспомогательныеДанные",1},
{10,
{"N",0},1,1},
{9,6df2bb92-558c-4453-9de4-e4176e8f93dc,"ОбластьДанныхОсновныеДанные",2},
{10,
{"N",0},2,1},