- В этой теме 28 ответов, 4 участника, последнее обновление 7 лет, 4 месяца назад сделано
.
-
Записи
-
Может вы мне подскажете в какую сторону мне тогда проще будет смотерть?
Думаю, нужно начать с настройки опроса по триггеру. А затем перейти к написанию запросов и хранимых процедур для работы с Вашей БД.
Ваша 1С на какой СУБД работает?Думаю, нужно начать с настройки опроса по триггеру. А затем перейти к написанию запросов и хранимых процедур для работы с Вашей БД
Спасибо за совет. С триггерами всё понятно, с БД не совсем. Сможете подсказать, где устанавливается период выполнения запросов у модуля экспорта в БД? И правильно ли я понял, что вызов запроса, записанного в модуле, выполняется по периоду и при изменении данных?
В моём случае, я пока-что не могу найти решения кода хранимой процедуры из-за того, что значение канала триггера раньше записывается в БД, чем данные других каналов. Соответственно, я не могу в теле процедуры взять нужные значения каналов и поместить в мою таблицу т.к. их еще нет. Но это, я думаю, вопрос больше к СУБД=)
Так же не совсем понятно, почему данные в таблице дублируются — это особенность модуля или неправильная настройка?
2019-02-20 14:42:11.935745 | 8001 | 0 | 0
2019-02-20 14:42:11.947698 | 8001 | 0 | 0
2019-02-20 14:43:12.093285 | 721 | 5 | 1
2019-02-20 14:43:12.093285 | 722 | 4 | 1
2019-02-20 14:43:12.093285 | 723 | 3 | 1
2019-02-20 14:43:12.093285 | 724 | 2 | 1
2019-02-20 14:43:12.105338 | 721 | 5 | 1
2019-02-20 14:43:12.105338 | 722 | 4 | 1
2019-02-20 14:43:12.105338 | 723 | 3 | 1
2019-02-20 14:43:12.105338 | 724 | 2 | 1
2019-02-20 14:43:13.227364 | 8001 | 0 | 0
2019-02-20 14:43:13.23936 | 8001 | 0 | 0
2019-02-20 14:44:12.180286 | 721 | 5 | 1
2019-02-20 14:44:12.180286 | 722 | 4 | 1
2019-02-20 14:44:12.180286 | 723 | 3 | 1
2019-02-20 14:44:12.180286 | 724 | 2 | 1где устанавливается период выполнения запросов у модуля экспорта в БД? И правильно ли я понял, что вызов запроса, записанного в модуле, выполняется по периоду и при изменении данных?
Запрос для каждого входного канала помещается в очередь на выполнение в тот момент, когда он поступает от Коммуникатора на Сервер.
По поводу дублирования — поищите здесь на форуме уже разбирались похожие вопросы.
На мой взгляд, значение триггера нужно записывать в отдельную таблицу, чтобы использовать его, когда будут приходить значения по каналам данных.
По поводу дублирования — поищите здесь на форуме уже разбирались похожие вопросы.
Понял в чем причина, спасибо.
Я пошел по предложенному Вами пути:
Есть 2 кп, один это триггер, второй это данные. Модуль автоуправления читает 2 кп при триггер = 1. Сервер получает данные и они отображаются в срезах. Вот только модуль экспорта в БД как-будто шалит. База данных пустая. Скрипты в модуле из мануала для Postgres. Стоит 11 Postgres. При перезагрузки коммуникатора записывается некая пачка данных, а потом опять тихо. Сможете подсказать, в какую сторону копать?Я пошел по предложенному Вами пути:
Есть 2 кп, один это триггер, второй это данные. Модуль автоуправления читает 2 кп при триггер = 1. Сервер получает данные и они отображаются в срезах. Вот только модуль экспорта в БД как-будто шалит. База данных пустая. Скрипты в модуле из мануала для Postgres. Стоит 11 Postgres. При перезагрузки коммуникатора записывается некая пачка данных, а потом опять тихо. Сможете подсказать, в какую сторону копать?Нашел в чем причина.
Какая была причина?
Не в бобине=) Некорретный триггер в БД, как следствие не правильно отрабатывающая функция и неправильное поведение
По поводу дублирования — поищите здесь на форуме уже разбирались похожие вопросы.
Нет, как оказалось, не понял.
При установке в коммуникаторе периода передачи на сервер равного 0 приходят только те данные, которые изменились — что для нас не подходит, т.к. некоторые данные и не предполагалось изменять, но они нужны для обработки.
При установки 1 секунды приходит следующее:2019-04-17 12:52:35.94572 | 61 | 0 | 1
2019-04-17 12:52:35.976992 | 61 | 0 | 1
2019-04-17 12:52:36.023894 | 141 | 11.1099996566772 | 1
2019-04-17 12:52:36.023894 | 142 | 12 | 1
2019-04-17 12:52:36.023894 | 143 | 13 | 1
2019-04-17 12:52:36.023894 | 144 | 14 | 1
2019-04-17 12:52:36.023894 | 145 | 15 | 1
2019-04-17 12:52:36.023894 | 146 | 16 | 1
2019-04-17 12:52:36.023894 | 147 | 17 | 1
2019-04-17 12:52:36.023894 | 148 | 18 | 1
2019-04-17 12:52:36.023894 | 149 | 19 | 1
2019-04-17 12:52:36.023894 | 150 | 0 | 1
2019-04-17 12:52:36.023894 | 151 | 1000 | 1
2019-04-17 12:52:36.023894 | 152 | 900 | 1
2019-04-17 12:52:36.023894 | 153 | 1 | 1
2019-04-17 12:52:36.023894 | 154 | 2 | 1
2019-04-17 12:52:36.023894 | 155 | 3 | 1
2019-04-17 12:52:36.023894 | 156 | 4 | 1
2019-04-17 12:52:36.023894 | 157 | 5 | 1
2019-04-17 12:52:36.023894 | 158 | 6 | 1
2019-04-17 12:52:36.023894 | 159 | 7 | 1
2019-04-17 12:52:36.023894 | 160 | 8 | 1
2019-04-17 12:52:36.023894 | 161 | 9 | 1
2019-04-17 12:52:36.023894 | 162 | 101 | 1
2019-04-17 12:52:36.023894 | 163 | 0 | 1
2019-04-17 12:52:36.055156 | 141 | 11.1099996566772 | 1
2019-04-17 12:52:36.055156 | 142 | 12 | 1
2019-04-17 12:52:36.055156 | 143 | 13 | 1
2019-04-17 12:52:36.055156 | 144 | 14 | 1
2019-04-17 12:52:36.055156 | 145 | 15 | 1
2019-04-17 12:52:36.055156 | 146 | 16 | 1
2019-04-17 12:52:36.055156 | 147 | 17 | 1
2019-04-17 12:52:36.055156 | 148 | 18 | 1
2019-04-17 12:52:36.055156 | 149 | 19 | 1
2019-04-17 12:52:36.055156 | 150 | 0 | 1
2019-04-17 12:52:36.055156 | 151 | 1000 | 1
2019-04-17 12:52:36.055156 | 152 | 900 | 1
2019-04-17 12:52:36.055156 | 153 | 1 | 1
2019-04-17 12:52:36.055156 | 154 | 2 | 1
2019-04-17 12:52:36.055156 | 155 | 3 | 1
2019-04-17 12:52:36.055156 | 156 | 4 | 1
2019-04-17 12:52:36.055156 | 157 | 5 | 1
2019-04-17 12:52:36.055156 | 158 | 6 | 1
2019-04-17 12:52:36.055156 | 159 | 7 | 1
2019-04-17 12:52:36.055156 | 160 | 8 | 1
2019-04-17 12:52:36.055156 | 161 | 9 | 1
2019-04-17 12:52:36.055156 | 162 | 101 | 1
2019-04-17 12:52:36.055156 | 163 | 0 | 1Всё, что я находил насчет дублей на форуме это касалось таймштампа и решалось игнором или апдейтом. Но я не нашел ошибок на стороне Postgres и данные то есть. Просто два раза с разницей в миллисекунды. Увеличение периода картины не меняет.
Буду признателен на ссылку, где это обсуждалось.Напомните, пожалуйста, как именно Вам нужно, чтобы передавались данные в БД?
В идеале хотелось бы пачками с канала 1 по канал n с одним таймштампом. Потом еще одна пачка и т.д.
Моя идея была в том, чтобы триггер срабатывал на значение 0, вычитывал до времени триггера со значением 1 и записывал в таблицу. На триггер со значением 1 не имеет смысл срабатывать, т.к. так одиночные инсерты из модуля дб и следующих данных еще нет.
Ну или подскажите примерный алгоритм триггеров чтобы корректно распарсивать такие данные. Я не смог с ходу придумать.Всё равно не обчень понятно, что нужно. Данные отправляются в БД после того, как получены Сервером от Коммуникатора. Коммуникатор отправляет данные на Сервер после опроса прибора.
Если проблема в дублировании, то нужно проверить, какие у Вас версии Сервера и Коммуникатора. По этой проблеме что-то исправлялось, по-моему.
Кстати, в следующей версии Коммуникатора появится опция, чтобы после опроса КП отправлять на Сервер все теги КП, а не только изменившиеся.
Если проблема в дублировании, то нужно проверить, какие у Вас версии Сервера и Коммуникатора.
Версия коммуникатора: 5.1.1.0
Версия Сервера: 5.1.1.0Данные отправляются в БД после того, как получены Сервером от Коммуникатора. Коммуникатор отправляет данные на Сервер после опроса прибора.
По опросу или по периоду передачи данных на сервер. По периоду передает все данные. Если период = 0, то только те, которые изменились.
Кстати, в следующей версии Коммуникатора появится опция, чтобы после опроса КП отправлять на Сервер все теги КП, а не только изменившиеся.
Т.е. при периоде = 0 буду приходить все данные? Это, как мне кажется, решит мою проблемму.
Я просто не понимаю, почему необходимо как-то распарсивать таблицу, приведенную мной выше таким образом, чтобы корректно селектить нужное значение из 2х строк, которые для меня являются одним и тем-же значением с разницей в 30 мс?
Можно-ли заставить отправлять Коммуникатор данные на Сервер по какому-то триггеру?
Версии у Вас актуальные.
В ближайшие дни выложу на форум ссылку на новую версию для сообщества — надеюсь, что проблема решится.чтобы корректно селектить нужное значение из 2х строк, которые для меня являются одним и тем-же значением с разницей в 30 мс?
Конечно, так быть не должно.
Можно-ли заставить отправлять Коммуникатор данные на Сервер по какому-то триггеру?
Триггером является завершение опроса КП. Коммуникатор не хранит данные в какой-либо очереди, поэтому сразу их отправляет на Сервер.
- Для ответа в этой теме необходимо авторизоваться.