Hello everyone! I'm a thunder worker.
This article records a problem in the historical alarm application of KingSCADA and its handling process.
1. Problem description
Recently, a customer encountered such a problem: when the historical alarm window interface is opened, the automatically loaded alarm information displays the alarm information of the past few days, but when the historical alarm information is queried by selecting the time range and the time period, the recent alarm information cannot be queried. Alarm messages for several days. what is the reason?
1. The information automatically loaded as shown below includes the alarm information of 2023-08-21.
2. After selecting the start time and end time, click Query Alarm Records. Only the alarm information with the latest date of 2023-08-19 can be queried.
2. Problem analysis
1. When the historical alarm window is automatically loaded, the alarm information loaded comes from the historical alarm buffer area.
2. When querying through the time range, the alarm data of the alarm database is queried.
3. Analysis of the latest alarm information generated failed to be stored in the alarm database.
4. Open the program directory and find the [AlarmData] folder.
5. Copy the Access database [Alarm&Event] to another location, open it and check whether there is alarm information in the past few days.
6. After checking that the alarm information of the last few days does not exist in the database, it means that the alarm information of the next few days has not been stored in the alarm database.
7. After checking, the size of [Alarm&Event] reaches about 2G, and the Access database has a 2G capacity limit.
8. After trying to clear the database, the latest alarm data can be stored normally.
3. Cause of the problem
Through analysis and testing, the cause of the problem is that the Access data capacity has reached the upper limit and the latest data cannot be stored.
4. Solution
1. The previous data can be automatically deleted by modifying the storage days of the alarm library.
Data retention time: Set the number of days for data retention in the alarm database. Alarm records that exceed the number of days will be automatically deleted by the system, and the number of storage days is 0-999. If the number of storage days is set to 0, it means permanent storage.
2. Replace other databases to store alarm data.
3. Perform regular manual backups and clear data.
5. Other related issues
1. User name: User name for logging in to the database or industrial library. This user needs to have data reading, data writing and system management permissions.
2. The historical alarm data saved in the KS alarm database
is 8 hours different from the local time (Beijing time). Yes, when KS saves the historical alarm data to the alarm database, the date and time are saved according to Greenwich Time, so the SQL statement is used When querying the alarm database, pay attention to time zone conversion. The following is an example of using a data set to query the alarm database.
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");
Note: When the KS alarm window uses SQL query, the same query conditions must be subtracted by 8 hours, but there is no need to convert the time zone when displaying the query results. The alarm window automatically converts the time zone.
6. Postscript
The above is a minor problem encountered by KingSCADA historical alarm query, and a record of the problem handling process. Friends who have the same problem can refer to it.