Регулирование записи алармов в БД

[KCD]

Добрый день!

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

[Diogen]

Добрый день!

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

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

[Larrrik]

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

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

[Генератор зла]

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

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

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

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

[Diogen]

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

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

[KCD]

Добрый день!

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

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

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

[KCD]

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

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

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

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

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

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

[Генератор зла]

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

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