Версия ЛЭРС УЧЁТ: 3.64
Сервер БД: PostgreSQL
Как в web так и в клиенте моргает обновление страницы + сбрасывает “курсор” выделения элемента.
1 лайк
Поддерживаю. Много лет мучаюсь, из-за того, что при автообновлении страницы улетает позиция курсора. Видимо, у разработчиков ЛЭРС очень мало настроено портов опроса, и они помещаются на одном экране. У меня не помещаются, и нужно, чтобы выделенная строка при обновлениях оставалась на месте:
@Sly, к теме обсуждения мой вопрос не относится, но хочется понять почему вы сделали именно так. Я вижу, что вы создали множество портов опроса, которые принимают подключения от LERS GSM LitePro. Фактически, вы используете их как стандартные модемы, по одному модему на сетевой порт.
Однако, LitePro поддерживает идентификацию, и они все могут подключаться к одному сетевому порту и обрабатываться одним портом опроса. Фактически, все эти порты вы можете закрыть и оставить только один. Почему вы выбрали именно такой способ с большим количеством портов опроса?
Один порт будет работать точно так же, никаких проблем со скоростью опроса не будет.
Действительно наш нынешний подход к обновлению списков показывает себя всё более неэффективно. Мы уже опробовали новый способ обновления на клиенте на списке сеансов опроса и он показал себя более стабильным. Поэтому проведём такие же работы и для списка служб и портов опроса.
Если можете, предоставьте доступ к системе, чтобы мы могли опробовать исправления на рабочей системе.
Поставили в план на 3.65.
Во-первых, так исторически сложилось. Получил от предшественников в таком виде.
Во-вторых, так проще искать лог-файл опроса. В один файл не будут попадать дампы от разных модемов.
В-третьих, при подключении “Стандартного GPRS-модема” появляется лог-файл с соответствующим названием, и я сразу вижу, когда, в какое время произошла попытка подключения конкретно нужного мне модема. Для “ЛЭРС GSM” я по дате лог-файла сразу вижу, когда произошло последнее подключение конкретного модема.
Минусов с большим количеством портов нет, количество достаточное, так что пихать все однотипные модемы на один порт не вижу смысла.
Вспомнил ещё, что много лет назад у меня были подозрения, что ЛЭРС УЧЕТ может путать данные от разных приборов, если несколько однотипных модемов опрашиваются через один порт. Разбираться с этим было очень сложно, поэтому пришлось идти обходным путём.
А почему для этого не подходит статистика GPRS модемов? Там для каждого модема есть история подключений.
Если вам часто нужны дампы опроса, может, вам подсказать как хранить их в базе данных? Тогда дамп можно будет просмотреть прямо из списка сеансов опроса через АРМ оператора, или веб-интерфейс. Конечно, это увеличит размер базы данных и время сохранения данных опроса, но может вам так будет удобнее?
К статистике GPRS модемов доверия намного меньше. Когда я подключаю новый модем, то, если где-то в настройках ошибся, например неправильно ввел идентификатор, то статистика ничего не покажет. А в папке с логами я просто стираю старые файлы, и жду, когда появится новый файл, у которого в имени вижу номер порта TCP. Модемы я создаю с именами, содержащими номер порта TCP. Если файл никак не появляется, то у меня есть все основания заняться проверкой доступности данного TCP порта снаружи.
В статистике CSD, помню, было очень мого глюков, связанных с разницей локального и глобального времени, поэтому остерегаюсь вообще любой статистике доверять в вашей программе 
В папку с логами я привык смотреть в первую очередь, статистиками пользуюсь редко.
да Боже упаси! Я у соседей наблюдал, как они пытались в БД хранить сканы договоров, актов и тому подобный мусор. На мой взгляд, это дичь.
Отдельный файлы дампов намного удобнее. Можно выделить и удалить ненужные файлы по дате. Можно файл взять и отправить в техподдержку ЛЭРС на изучение
Так это у меня поэтому вкладка “Дамп обмена” в “Сеансах опроса” всегда пустая? Когда-то давно она дамп умела показывать на АРМ оператора, потом всё пропало…
Аналогичная ситуация. Было очень удобно пока это (недолго) работало.
Мы выключили хранение данных по умолчанию, так как увидели, что это увеличивает время на сохранения данных сеанса опроса. А это лавинообразно увеличило у нас количество сообщений. Можно включить и хранить их в основной БД, или в отдельном файле sqlite.
Это не мусор, а диагностические данные. Они хранятся временно и автоматически очищаются через 7 дней. Но как я говорил, увеличивают время на сохранение данных опроса. Для систем, у которых ресурсов мало это критично, поэтому пришлось по умолчанию выключить для всех.
Если у вас достаточно производительная система, можно включить и видеть дампы в журнале опроса. Оттуда же их можно сохранить в XLSX, чтобы отправить нам.
Включить можно в конфигурационном файле сервера, или в параметрах окружения, если вы используете docker.
В XML файле нужно добавить блок
<modules>
<poll>
<PollDumpStorageDays>7</PollDumpStorageDays>
</poll>
</modules>
Это включит хранение дампов на 7 дней.
В Docker надо выставить пременную окружения
LERS_SERVER_Modules__Poll__PollDumpStorageDays: 7
1 лайк
Добавлю, что при этом дамп будет храниться в отдельном файле в формате sqlite, чтобы не увеличивать размер основной БД. Но если используется не SQL Server Express, можно включить хранение в основной базе.
За это отвечает параметр
<storage>
<RelationalPollDumps>true</RelationalPollDumps>
</storage>
Или LERS_SERVER_Storage__RelationalPollDumps: true
А в докере где хранится sqlite?
В контейнере это папка /var/LERS. Когда вы запускаете контейнер, вы монтируете её в том, или в папку в файловой системе вашего хоста.