www.InTouch.su

Добрый день!

Подскажите, каким образом можно регулировать запись алармов и событий в БД, таким образом, чтобы не забивать БД лишней информацией, например, записывать только сигналы возникновения событий, но не исчезновения. Скажем так, чтобы не фильтрами выбирать необходимую информацию, а не записывать лишнюю ?

KCD писал(а):Добрый день!

записывать только сигналы возникновения событий, но не исчезновения

Конкретно вот это, можно реализовать, если не ставить галку Alarm в настройках тега, а включить его как Event.

Diogen писал(а):Конкретно вот это, можно реализовать, если не ставить галку Alarm в настройках тега, а включить его как Event.

Только вот при этом в базу у Вас начнет писаться любое изменение значения параметра, что раздует ее гораздо больше. Ну а алармы соответственно перестанут генерироваться.
Оно Вам нада?

Diogen писал(а):Конкретно вот это, можно реализовать, если не ставить галку Alarm в настройках тега, а включить его как Event.

А не проще почитать IT_AlarmsAndEvents.PDF и понять разницу между Detailed и Consolidated моделями хранения алармов в БД?

KCD писал(а):например, записывать только сигналы возникновения событий, но не исчезновения.

Вы, случаем, не на ЧАЭС работаете? Там тоже не понадобилась запись выхода из аларма.

Larrrik писал(а):Только вот при этом в базу у Вас начнет писаться любое изменение значения параметра, что раздует ее гораздо больше. Ну а алармы соответственно перестанут генерироваться.
Оно Вам нада?

Прощу прощения, не уточнил, что это относится только к дискретным алармам.

Diogen писал(а):

KCD писал(а):Добрый день!

записывать только сигналы возникновения событий, но не исчезновения

Конкретно вот это, можно реализовать, если не ставить галку Alarm в настройках тега, а включить его как Event.

Если не ставить галку 1, то в Current Alarm Mode в клиенте алармов отображаться не будет.
Если не ставить галку 2, то записываться в БД не будет, насколько я пробовал.

Генератор зла писал(а):

Diogen писал(а):Конкретно вот это, можно реализовать, если не ставить галку Alarm в настройках тега, а включить его как Event.

А не проще почитать IT_AlarmsAndEvents.PDF и понять разницу между Detailed и Consolidated моделями хранения алармов в БД?

Спасибо, ознакомился.

Генератор зла писал(а):Вы, случаем, не на ЧАЭС работаете? Там тоже не понадобилась запись выхода из аларма.

Да уж, зачем мелочиться по пустякам, когда ничего уже не поможет

Интересовал вопрос еще, даже не только записи исчезновения событий, а еще всякие дополнительные записи, типа UNACK_ALM, UNACK_RTN and so on...
Вроде бы одно событие появляется, а записей - куча...

KCD писал(а):Интересовал вопрос еще, даже не только записи исчезновения событий, а еще всякие дополнительные записи, типа UNACK_ALM, UNACK_RTN and so on...
Вроде бы одно событие появляется, а записей - куча...

Эта "куча записей" - "для прокурора". Именно по ним восстанавливают хронологию событий: когда возникла авария (UNACK_ALM), когда оператор с ней ознакомился (ACK_ALM), какие действия и когда предпринял, когда аварийная ситуация вернулась к норме (ACK_RTN). И по этой хронологии оценивают своевременность и грамотность действий. И, как следствие, определяют кому раздавать "пряники".
Вот такая "куча ненужного мусора". Если для Вас лично это лишнее, не пользуйтесь БД для аварий, показывайте лишь текущие. Жизнь резко упросится.