Столкнулся тут можно сказать впервые в жизни с 1C на одном из наших предприятий, местный разработчик перетаскивал базу с одного сервака на другой вместе с логами, логи в формате lgd (SQLite)....
Дальше пожалуй крик души... оно не поднялось, точнее база поднялась, а вот в журнале регистрации кракозябры...
При чем кракозябры на старых записях, а новые пишутся и читаются нормально...
Ладно думаю, где наша не пропадала, выясняю что это SQLite, радуюсь и лезу внутрь.... и тут... Честно, у меня челюсть отвалилась, кодировка символов в строковых полях SQLite или UTF-16 или UTF-8, какого же было мое удивление когда я увидел в табличке EventLog в поле data "кракозябры"... Полез по форумам и поискам, про это почти никто не пишет, ладно... выдираем строчку, пихаем в анализатор кодировок и выясняем старые записи это ошибочная конвертация windows-1252(latin1) в UTF-8, новые записи windows-1251 в UTF-8, точнее не конвертация, а они лежат в этих кодировках но SQLite их считает UTF-8 и естественно читает как бред...
После определенных мыторств пишу скрипт на питоне, который мне таки показал ЭТО по русски, но проблеммы это не решает, так как доступ к журналу мне нужен из 1С, запихать обратно в столь кривом виде стандартными средствами мне не удалось, соответственно полезли разбираться дальше.... и тут барабанная дробь, выяснилось следующее:
На старом сервере (достался в наследство) стояла локаль для non-unicode программ - English, на новом Russian и эти.... пиииип... "разработчики" платформы судя по всему используют какую-то библиотеку для генерации/парсинга JSON, которая
1) завязана на эту настройку
2) выдает результат в однобайтной кодировке
3) они это как есть пихают в SQLite!
В общем, установка локали на втором сервере в English позволила засосать логи, собственно сорри за такую длинную предысторию, теперь вопросы
1) Можно ли это как нибудь вылечить, ну то есть если у меня лежит в SQLite JSON то я ожидаю что у него локаль будет как у соседних текстовых полей, которая кстати UTF-8!
2) Можно ли как-то научить 1с не класть в этот лог события типов "_$Transaction$_.Begin", "_$Transaction$_.Commit" убив записи с этими типами (для анализа бизнес событий они практической ценности не несут) lgd файл сократился с 210ГБ до 15ГБ
P.S. Еще раз сорри за много букв, но накипело....
Дальше пожалуй крик души... оно не поднялось, точнее база поднялась, а вот в журнале регистрации кракозябры...
При чем кракозябры на старых записях, а новые пишутся и читаются нормально...
Ладно думаю, где наша не пропадала, выясняю что это SQLite, радуюсь и лезу внутрь.... и тут... Честно, у меня челюсть отвалилась, кодировка символов в строковых полях SQLite или UTF-16 или UTF-8, какого же было мое удивление когда я увидел в табличке EventLog в поле data "кракозябры"... Полез по форумам и поискам, про это почти никто не пишет, ладно... выдираем строчку, пихаем в анализатор кодировок и выясняем старые записи это ошибочная конвертация windows-1252(latin1) в UTF-8, новые записи windows-1251 в UTF-8, точнее не конвертация, а они лежат в этих кодировках но SQLite их считает UTF-8 и естественно читает как бред...
После определенных мыторств пишу скрипт на питоне, который мне таки показал ЭТО по русски, но проблеммы это не решает, так как доступ к журналу мне нужен из 1С, запихать обратно в столь кривом виде стандартными средствами мне не удалось, соответственно полезли разбираться дальше.... и тут барабанная дробь, выяснилось следующее:
На старом сервере (достался в наследство) стояла локаль для non-unicode программ - English, на новом Russian и эти.... пиииип... "разработчики" платформы судя по всему используют какую-то библиотеку для генерации/парсинга JSON, которая
1) завязана на эту настройку
2) выдает результат в однобайтной кодировке
3) они это как есть пихают в SQLite!
В общем, установка локали на втором сервере в English позволила засосать логи, собственно сорри за такую длинную предысторию, теперь вопросы
1) Можно ли это как нибудь вылечить, ну то есть если у меня лежит в SQLite JSON то я ожидаю что у него локаль будет как у соседних текстовых полей, которая кстати UTF-8!
2) Можно ли как-то научить 1с не класть в этот лог события типов "_$Transaction$_.Begin", "_$Transaction$_.Commit" убив записи с этими типами (для анализа бизнес событий они практической ценности не несут) lgd файл сократился с 210ГБ до 15ГБ
P.S. Еще раз сорри за много букв, но накипело....
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Это не ко мне вопрос, а к глав буху, иметь возможность посмотреть за 3 года кто какой документ трогал. На сколько я понимаю в старом формате это будет весить еще больше и не уаерен что во время конвертации можно работать в системе. Где менять написано в доках, не надо ссылок. Вообще не вижу ничего странного в желании хранить лог того кто и что делал, но вот логируемые события хочется настраивать. Не, я могу раз в месяц цепляться за файл sqlite и грохать ненужные типы событий, благо если это делать пеоиодически, то и файл до таких объемов не вырастит, а пара десятков гигов это ерунда. Но блин, можно же было сделать настройку или я ее просто не нашел. Старый формат еще неудобен с точки зрения поиска по нему в lgd хоть индексы построены.
(5)
а по хорошему - запрет на проведение документов вчерашним числом
и никто не будет никого трогать.
ну хорошо, увидела, что "трогал" человек, который уволен год назад.дальше что ?
в музей.история. а потом - стоп, а почему админ не досмотрел ....
так что кроме логов есть "история изменений"
вобщем , я так понимаю, вы здесь на долго :)
иметь возможность посмотреть за 3 года кто какой документ трогал.
а по хорошему - запрет на проведение документов вчерашним числом
и никто не будет никого трогать.
ну хорошо, увидела, что "трогал" человек, который уволен год назад.дальше что ?
в музей.история. а потом - стоп, а почему админ не досмотрел ....
так что кроме логов есть "история изменений"
вобщем , я так понимаю, вы здесь на долго :)
Питон я поосто знаю, как и еще с десяток языков, просто для питона нашлась библиотека, которая умеет работать с НАСТОЛЬКО кривой кодировкой. Мне только ошибок мало, требуется именно лог работы пользователей, а тут, как кто-то написал или все или ничего.
Ну и кодировка поля data это банальный програмный баг платформы, 1с вообще их как-то правит или где-то может есть issue tracker? Сорри, просто не сталкивался... даже в индусском OEBS таких багов нет.
Ну и кодировка поля data это банальный програмный баг платформы, 1с вообще их как-то правит или где-то может есть issue tracker? Сорри, просто не сталкивался... даже в индусском OEBS таких багов нет.
(11) господи... тут есть смайлик facepalm?....
когда мы писали системы на питоне старались pep8 придерживаться, но какое это имеет отношение? прочитать этот лог с восстановлением кодировки это 15 строк кода.
В общем по существу инфы как я понимаю не будет.... ладно...
Подписка ИТС есть... надо их пнуть нитереса ради
когда мы писали системы на питоне старались pep8 придерживаться, но какое это имеет отношение? прочитать этот лог с восстановлением кодировки это 15 строк кода.
В общем по существу инфы как я понимаю не будет.... ладно...
Подписка ИТС есть... надо их пнуть нитереса ради
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот