Удаление записей журнала регистрации *.lgd #789201

Утро доброе. Платформа 1С:Предприятие 8.3 (8.3.7.1917), серверный вариант. 1) Подключаюсь к базе удаляемого журнала регистрации: 2) Создаю фильтр для удаления периода журнала регистрации: Записи удаляются все вроде бы красиво. Но иногда после такого удаления ЖурналРегистрации накрывается медным тазиком. В него перестают записываться новые события. Длится  это состояние до тех пор пока не перезагрузишь сервер 1с предприятия. В базе очищаемого журнала,  постоянно работают пользователи. По какой причине удаляемый журнал "клинит" ????

Я удаляю старые записи, а кто-то из пользователей проводя документы, добавляет записи в журнал регистрации...  Возможно по этому что-то ломается в ЖР и но перестает работать? Или это не причем?

Ошибка формата файла журнала регистрации sqlite3_exec failed: SQL logic error or missing database db: C:Program Files1cv8srvinfo eg_1541cdd9b47-17e8-45d8-b4bc-054d96b4943d1Cv8Log1Cv8.lgd sql: CREATE TEMP TABLE _ForDelete (rowID INTEGER PRIMARY KEY); Получается, что при удалении записей ЖурналаРегистрации , активных пользователей не должно быть ?

да. А Вы 24/7 работаете?

ага

пичалька. А сколько по времени может длится очистка журнала?

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

от минуты в выше, все зависит от загрузки системы и объема самого журнала регистрации. Обработку по очистке запускал каждые 3 часа... Две недели работало без коллизий, а потом журнал сломался. А есть ли какое решение, что при работающей обработке по удалению записей журнала, приостанавливать деятельность пользователей ??

+ ну это если у вас не стратегический поток данных 24/7, в любом супермаркете полюбому спят ))

оно как бы раз на раз не приходится...  то расчет С/С запустят, то проведение документов поставят..

у нас производство, а не магаз ))

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

журнал копируется в отдельную базу . Скопированные записи удаляются.

Приостановить.... а если процесс уже юзверем запущен??....

+13 Кроме того есть еще фоновые задания..

одна ситуация, когда при удалении вот такое выдается: sqlite3_exec failed: database table is locked db: C:Program Files1cv8srvinfo eg_1541cdd9b47-17e8-45d8-b4bc-054d96b4943d1Cv8Log1Cv8.lgd sql: DROP TABLE _ForDelete; Журнал заблокирован. В такой ситуации можно подождать немного и еще раз попытаться удалить... но иногда журнал ломается напрочь, помогает только презагрузка.

Вот... не знаю что придумать... пока все пишется в журнал и он растет растет и растет..

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

на платформе 1С:Предприятие 8.3 (8.3.6.2152) пока не удалось испортить журнал регистрации. На тестовой базе запустил перепроведение документов...  запустил удаление.. Получил ошибку: Ошибка формата файла журнала регистрации sqlite3_exec failed: SQL logic error or missing database   но при этом журнал продолжал отображать новые записи генерируемые проведением документов. А на 1С:Предприятие 8.3 (8.3.7.1917) новые записи не добавлются. Ситуацию исправляет только перезагрузка.

а зачем удаленно подключаетесь?

хотел сделать отдельную конфигурацию, которая будет забирать к себе журнал регистрации и очищать загруженные данные из журнала

А чем стандартный метод не устраивает? Он вроде и при работающих пользователях прекрасно ЖР сокращает.

стандартный  - это через конфигуратор?

с отсутствующими пользователями журнал регистрации удаляется на ура...

Ну да. Проверил, ЖР сократился, когда был сеанс запущен на отладку.

Получается следущее: Если есть желание переносить журнал регистрации в отдельную базу, то для этого надо хранить журнал регистрации в текстовых файлах, с  разбивкой по дням (настраивается в конфигураторе).  К примеру если сегодня 18 число, то все файлы что меньше 18 числа можно загрузить и удалить программно, 18 число будет занято системой. Попробую пойти по такому вот пути...

Для истории, готовое решение:

А зачем его удалять? Я вообще считаю, что прикладной ЖР должен быть частью информационной базы, то есть храниться в той же базе, что и данные. Это достаточно ценная информация, чтобы хранить её "в каком-то каталоге с непонятным именем на сервере приложений".

Да, согласен, такое мнение существует.

Ты своё мнение озвучь )) В чём выгода очистки журнала?

ЖР не разрастается.

Ну и пусть разрастается. Что тебе от этого?

когда журнал несколько гигов, начинаются тормоза. Архивировать журнал - хорошая практика. Но, всё же принято это делать штатными средствами

Спасибо. Именно на это я и хотел вывести ТС.

Мопед не мой, я только дал объяву: Максим Боголепов "Сокращение журнала регистрации в 1С:Предприятие версии 8.3" (в статье ссылки на скачивание РаботаСЖурналомРегистрации83.epf и СократитьЖурналРегистрацииПериод.epf)