Конвертация журнала регистрации из 1С 8.2 в SQLite 1С 8.3, слияние журналов регистрации в SQLite 1С 8.3

04.12.2017 14 Comments

Администрирование, Администрирование данных 1С

,

    Конвертация журнала регистрации
Конвертация журнала регистрации из 1С 8.2 в SQLite 1С 8.3, слияние журналов регистрации в SQLite 1С 8.3. Обработка на 1С 8.2 / 8.3.

Журнал регистрации в 1С 8.3 хранится в виде базы данных SQLite , в отличие от 1С 8.2, где журнал регистрации хранится в двух и более файлов не совсем очевидной структуры. Данная обработка предназначена для дополнения приемника информацией из источника. Источником может служить журнал регистрации обеих версий (выбирается lgf в случае 8.2 и lgd в случае 8.3). Приемником — только журнал регистрации 1С 8.3 и он обязательно должен существовать (обработка не создает новый файл, а дополняет существующий корректный файл, созданный самой 1С-кой). Что может обработка:

  • Добавление журнала регистрации 1С 8.2 в журнал регистрации 1С 8.3
  • Добавление журнала регистрации 1С 8.3 в журнал регистрации 1С 8.3

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

  • Конвертация старого журнала регистрации в новый на SQLite . Для тех, кто поленился сделать это непосредственно при переходе на новую платформу, а теперь хранит старые журналы отдельно и ищет в них информацию вручную. Ну или для эстетов =)
  • Объединение старых журналов регистрации с целью прямого доступа посредством SQLite (в т.ч. на платформе 8.2). Это пригодится тем, кто хочет делать отчеты по журналу регистрации в 1С 8.2, но желает быстродействия.
  • Объединение новых журналов регистрации после каких-либо манипуляций с ними. Подойдет тем, кто постоянно переносит журнал регистрации на отдельный диск в целях экономии места на сервере. Ну и тем, у кого просто по каким-либо причинам журналы от одной разделились.

Проблем с русскими буквами нет, я их пофиксил еще на этапе разработки (кстати, метод требует очень много дисковых операций). Для использования обработки необходимо установить SQLite на клиент, с которого будет осуществляться запуск. Используется для подключения "DSN=SQLite3 Datasource", вроде при установке SQLite она должна будет прописаться самостоятельно. Если нет, то прописывать нужно будет для 32-битной версии. Собственно, правильная установка SQLite уже за рамками данной публикации.

Из практики. Обработка использовалась для конвертации журнала 3.2 Гб старого формата в новый. Занимало это до 15 часов. При этом выходной файл будет в полтора-два раза больше или около того, потому что это уже база данных и у нее присутствует индексация. При слиянии двух новых журналов регистрации совсем не важно, кто будет источником, а кто приемником — на хронологию событий в отображении это не повлияет. Всего через нее прошло 20 Гб старых журналов и примерно столько же новых. Ошибок обнаружено не было.

Если файл SQLite не открывается и выдает ошибку (после вытаскивания его из под базы), то его можно восстановить при помощи утилиты из комплекта SQLite3, информация есть в сети. Не спешите его хоронить. Если же сбой произошел при работе данной обработки, то операцию конвертации следует повторить с самого начала. Не забывайте сохранять копию файла-приемника для таких случаев.

Обработка идет одним файлом без каких-либо дополнений. Авторство моё.

Related Posts

14 Comments

  1. BigB

    А разве в конфигураторе нельзя сконвертировать?

    Reply ↓
  2. Euroset1

    (1)

    Можно, но только один раз при переходе. Но как правило у админов находится та самая папка, куда складывали оставшиеся файлики. И конечно же забыли их перелить на сервер для конвертации.

    Reply ↓
  3. asved.ru 

       sessionDataSplitCode = «0»;   // мы его не копируем. Иначе пришлось бы тянуть еще 5 непонятных таблицц

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

    Но все равно спасибо.

    (2)

    Можно, но только один раз при переходе

    Не совсем так: берем пустую файловую базу, удаляем из ее каталога lgd, подбрасываем ей файлики lgf/lgp и конвертируем. Минус в том, что для автоматизации процесса приходится задействовать всяческие autoit, т.к. все управляется только в графическом интерфейсе.

    И несколько заклинаний для быстродействия записи sqlite.

    pragma mmap_size=1073741824;
pragma cache_size=32768;
pragma journal_mode=OFF;
pragma synchronous=OFF;
pragma temp_store = MEMORY;
    Reply ↓
  4. Euroset1

    (3)

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

    Касаемо пустой базы — это логично, но все равно файлов будет много, а их потом сливать надо в один. Стандартными методами это не сделать, так как там справочники могут иметь разные индексы и понеслась.

    Насчет заклинаний — о них на момент разработки не знал. Но это почти не важно — ведь львиная доля времени приходится на дисковые операции. А именно, на процесс преобразования одной кодировки в другую))) Ибо 1С классная платформа.

    Reply ↓
  5. Euroset1

    (3)

    sessionDataSplitCode.

    Я чуть уточню, что имел ввиду. Из журналов около сотни исследуемых баз (как 8.2, так и 8.3 версии клиента) ни в одной не был заполнен этот ключ. Везде ноль.

    Reply ↓
  6. asved.ru

    (5)

    http://v8.1c.ru/overview/Term_000000788.htm

    Этот механизм используется, например, в 1С:Fresh

    Reply ↓
  7. Euroset1

    (6)

    В таком случае, для работы с подобными механизмами данная обработка подойдет лишь частично.

    Reply ↓
  8. Euroset1

    Для себя открыл еще один способ применения данной обработки. Если у вас есть один отказоустойчивый кластер, который содержит несколько физических серверов (только для 8.3), то при сбое одного из центральных серверов журнал регистрации будет писаться согласно требований назначения функциональности на другой сервер. В итоге после восстановления работоспособности основного сервера, на который назначен высший приоритет для сервиса журнала регистрации, имеем два физических sqlite файла. Один из них основной на основном. Второй — это кусок за период сбоя. Чтобы этот кусок перелить в основной журнал достаточно на 5-10 минут остановить службу (для высвобождения журналов) и воспользоваться обработкой. Если конечно не используется редкий функционал «разделения данных».

    Reply ↓
  9. Euroset1

    Я тут задумал воспользоваться этой разработкой, но драйвер забыл откуда брать и как ставить. Поэтому потратил около 2 часов на воспоминание того момента, откуда брать драйвер и как его устанавливать. Раз уж потратил, то приобщу эти знания сюда.

    Итак, нам нужно не просто какой-то драйвер SQLite, а именно ODBC драйвер. Потому что данная обработка использует доступ через ADODB Connection. На родном сайте есть лишь DLLка и куча бесполезной документации. С этой DLLкой ничего не сделать, она бесполезна с точки зрения данной обработки. Касаемо ODBC драйвера, то он есть по ссылке ODBC драйвер для SQLite3. Забираем драйвер той разрядности, которой у нас клиент, потому что обработка выполняется на клиенте и файлы располагаются там же. Обычно это 32-битная версия. Далее инсталлируем его через далее-далее-готово. И скорее всего, больше ничего делать не придется.

    К моему великому удивлению, за несколько лет в сети ни одного толкового мануала по поисковому запросу не выходит. Просто тупо как поставить ODBC для скулайт. Так что, кому-то поможет, надеюсь.

    Reply ↓
  10. victor_k

    Спасибо помогло! Скачал. Добавил обычную форму. Объединил разорванный журнал в БП 2.

    Reply ↓
  11. victor_k

    (10) К сожалению не корректно объединяет. Работа в конфигурации БП 2, с объединенным журналом с помощью данной обработки стала не стабильна, а точнее не возможна. При входе и открытие документов зависание, на сервере 1С в таблице сеансов имя пользователя отсутствовало. Похоже, что то с драйвером ODBC или алгоритмом слияния, надо разбираться.

    Reply ↓
  12. Euroset1

    (11)

    Я столько раз ее использовал и на 8.2 и на 8.3 релизах, что в такой ситуации скорее грешил бы на релиз или на изначально разрушенные данные в одном из файлов. Попробуйте при помощи утилиты sqlite.exe пошаманить над исходными файлами. Какие-нить пересчеты индексов, восстановление и вакуум прописать. А потому уже сливать файлы. Мне разок пришлось это сделать.

    Чтобы вы понимали масштаб моего тестирования. Использовано на более чем 20 рабочих баз, более 100 раз всего. В ситуациях, когда приходилось удалять БД в консоли кластера и заново их создавать на этом или ином сервере. Там меняется гуид базы и создается новый журнал, не всегда получается выключать службу и подпихивать сразу старый заместо нового.

    И все же советую использовать только в управляемом приложении с родной формой в тонком клиенте.

    Reply ↓
  13. victor_k

    (12) Оказалось, что каким то образом потерялись права на файл журнала регистрации для учетной записи под которой запускается сервер 1С. Завтра в рабочем режиме пользователи протестируют, тогда и отпишусь окончательно .

    Reply ↓
  14. victor_k

    (12) Вроде все хорошо, полдня в рабочем режиме полет нормальный! Еще раз спасибо!

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *