【KingSCADA】问题处理:记录KS历史报警查询异常

哈喽,大家好!我是雷工。
本篇记录KingSCADA的历史报警应用中的一个问题,及处理过程。

一、问题描述

最近客户遇到这么一个问题:当打开历史报警窗界面,自动加载的报警信息中有显示最近几天的报警信息,但当通过选择时间范围,通过时间段查询历史报警信息时查询不到,最近几天的报警信息。是什么原因?

1、如下图自动加载的信息有2023-08-21的报警信息。

在这里插入图片描述

2、当选择开始时间和结束时间后,点击查询报警记录,只能查询到最新日期为2023-08-19的报警信息。

在这里插入图片描述

二、问题分析

1、历史报警窗自动加载时,加载的报警信息来自历史报警缓存区。
2、当通过时间范围查询时是查询的报警数据库的报警数据。
3、分析最新产生的报警信息未能存储到报警数据库中。
4、打开程序目录,找到【AlarmData】文件夹。

在这里插入图片描述

5、将Access数据库【Alarm&Event】复制到其他位置,打开查看其中是否有最近几天的报警信息。

在这里插入图片描述

6、经查看库中不存在最近几天的报警信息,说明后面几天的报警信息未能存入报警库。
7、经查看【Alarm&Event】大小达到2G左右,而Access数据库有2G容量限制。
8、尝试清空数据库后,最新的报警数据可以正常存储。

三、问题原因

通过分析及测试,问题原因为Access数据容量达到上限导致最新数据无法存储。

四、解决办法

1、可通过修改报警库的存储天数,自动删除之前的数据。

在这里插入图片描述

数据保留时间: 设置报警数据库中数据保存的天数,超过天数的报警记录将被系统自动删除,保存天数为0-999。如果保存天数设置为0,时表示永久保存。

2、更换其他数据库存储报警数据。
3、定期手动备份,并清空数据。

五、其他相关问题

1、用户名:登录数据库或工业库的用户名。该用户需要有数据读、数据写和系统管理的权限。
2、KS报警数据库里保存的历史报警数据与本地时间(北京时间)差8小时
是的,KS保存历史报警数据到报警数据库时,日期时间是按照格林威治时间保存的,因此在用SQL语句来查询报警数据库时,要注意时区的转换,下面是一个使用数据集查询报警数据库的例子。

string StartTime,EndTime;
string StartTime1,EndTime1;
StartTime1=UIDateTime1.Value;//获取查询的起始时间字符串
EndTime1=UIDateTime2.Value;//获取查询的结束时间字符串
StartTime=TransDateTimeByTimeZone(StartTime1,"8","0");//将查询的起始时间从东8区北京时间转化为0时区格林威治时间
EndTime=TransDateTimeByTimeZone(EndTime1,"8","0");//将查询的结束时间从东8区北京时间转化为0时区格林威治时间
string whe="select AlarmTime,TagName,AlarmValue from Alarm"+" where AlarmTime>=#"+StartTime+"# and AlarmTime<#"+EndTime+"#";
KDBGetDataset("Dataset1", "DSN=Alarm&Event", whe);
KDBEditDataset1("Dataset1", 0, "0", "8");//将数据集的日期时间列从0时区(格林威治时间)转换到8时区(北京时间)。
Report1.SetDataset1("Dataset1");

注:KS的报警窗口使用SQL查询方式时,同样查询条件也要减8小时,但显示查询结果不用转换时区了,报警窗口自动转换时区。

六、后记

以上为KingSCADA历史报警查询遇到的一个小问题,及问题处理过程的记录。有同样问题的小伙伴可以参考。

猜你喜欢

转载自blog.csdn.net/u013097500/article/details/132495955
ks
今日推荐