# When a new alarm, lose a point of historical **URL:** \ **Category:** Ignition\ **Created:** [November 7, 2012, 10:38pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387 "2012-11-07T22:38:05Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![2Gi\_Technologie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/2gi_technologie/32/3307_2.png) [@2Gi\_Technologie](https://forum.inductiveautomation.com/u/2Gi_Technologie)\ **Post date:** [November 7, 2012, 10:38pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/1 "2012-11-07T22:38:05Z")
Hello, I met a strange problem, I do not see any reason. I historizes one SQLTag everything goes well, a new alarm arrives I lose a point of history. I do not know or watch … In an analog variable historized red, blue variable with an alarm. Whenever there is an alarm on the GATEWAY I lose the history. I try to change the history SCANCLASS but in any case I lose a historic thank you ![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/b/b0af377d66a7623ea2c0912e3692e8b68cb55f6f.png) ---
**Author:** ![Michael.Stofan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.stofan/32/3342_2.png) [@Michael.Stofan](https://forum.inductiveautomation.com/u/Michael.Stofan)\ **Post date:** [November 7, 2012, 10:57pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/2 "2012-11-07T22:57:02Z")
It looks like your historical data is going to bad quality, which won’t be plotted on an easy chart. It’s interesting that the alert seems to correlate with bad quality. What are the specifications of your Ignition Gateway system (number of cores, RAM, etc…)? What version of Ignition are you running? What type of event does the alert represent? ---
**Author:** ![2Gi\_Technologie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/2gi_technologie/32/3307_2.png) [@2Gi\_Technologie](https://forum.inductiveautomation.com/u/2Gi_Technologie)\ **Post date:** [November 8, 2012, 11:24pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/3 "2012-11-08T23:24:30Z")
After doing various tests it works well with little SQLTag. So I think it’s a problem of my computer performance. In short I 200 analog variables to historicize all 500ms and 2,000 alarms. My alarms are on SQLTag on boolean change (to trace the changes). There is no connection between the analog and alarm on my curve. It seems that when an alarm GATEWAY manages it blocks a historical cycle. With a history of 1000 scanclass I have the same problem I lose one when I have a new alarm. ignition V7.5.5 beta 2GB RAM 4 cores Ubuntu 12.04 LTS MySQL I look for the rest tomorrow I try to make a transaction history group of 200 analog 500ms cycle, except that it works well in the field in the MySQL table t\_stamp I do not milliseconds (that is a DateTime field), is’t possible to have? Thank you for your help. ![:prayer:](https://us1.discourse-cdn.com/inductiveautomation/original/1X/e5a7e3b63facc151ea73e3b45db7bdb3d4bdc316.gif ":prayer:") ---
**Author:** ![Michael.Stofan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.stofan/32/3342_2.png) [@Michael.Stofan](https://forum.inductiveautomation.com/u/Michael.Stofan)\ **Post date:** [November 9, 2012, 1:01am UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/4 "2012-11-09T01:01:56Z")
The only real way to store milliseconds in MySQL is to use a bigint and store the value as unix time. It’s the same method we use for SQLTags history. I hope that helps clear up your question. As far as your logging vs alerting problem, it is possible that it is performance related. Could you post up a thread dump from the gateway control utility? ---
**Author:** ![2Gi\_Technologie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/2gi_technologie/32/3307_2.png) [@2Gi\_Technologie](https://forum.inductiveautomation.com/u/2Gi_Technologie)\ **Post date:** [November 9, 2012, 1:55pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/5 "2012-11-09T13:55:26Z")
I understand in “group transaction history” I can not get the milliseconds? the “t\_stamp” is datetime. To confirm that my problem does not come from the purchase I made a screenshot: - The green rectangle represents the history 500ms standart TagSql - The blue rectangle represents the result of my transaction history 500ms Group The two representations are the same variable. I see in my history group transation value changes and not in history I also join you dump thread Ubuntu 12.04 LTS Intel® Core™ i5-2510E CPU @ 2.50GHz × 4 32-bit 2Go RAM Gateway 7.5.5-beta1 (b1208) | 32-bit thank you ![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/a/a346c84f27901d2933b8e545cd71bdfc0782abe5.png) [thread-dump003.txt](https://us1.discourse-cdn.com/inductiveautomation/original/2X/d/dd73e438970e19e1a6ce85d3385b3147aceb94d6.txt) (91.1 KB) ---
**Author:** ![Colby.Clegg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/colby.clegg/32/3282_2.png) [@Colby.Clegg](https://forum.inductiveautomation.com/u/Colby.Clegg)\ **Post date:** [November 9, 2012, 5:39pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/6 "2012-11-09T17:39:52Z")
From the thread dump, I can see that some tags are executing queries to get their values. From the fact that it shows up in the dump, it either means that the queries are taking some time, or there are many of them. I would guess that you are using the same scan class for tag execution and scan class execution. The long execution time for query based tags is causing the scan class execution to take a long time, which in turn makes the data “stale” in the historical database (and causes values to be missed). I would recommend the following: separate scan classes for history and execution, and a separate execution scan class for the expression tags. Going further, it may be possible to improve the tag query performance with better indexes or a different where clause, but that’s a different issue. There should be a way to get the OPC tags to store history with no gaps. The machine specs are more than fine, it should easily handle this. Regards, ---
**Author:** ![2Gi\_Technologie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/2gi_technologie/32/3307_2.png) [@2Gi\_Technologie](https://forum.inductiveautomation.com/u/2Gi_Technologie)\ **Post date:** [November 12, 2012, 8:01pm UTC](https://forum.inductiveautomation.com/t/when-a-new-alarm-lose-a-point-of-historical/5387/7 "2012-11-12T20:01:22Z")
Colby thank you, it works very well. You’re doing a very good job on the forum, congratulations to the whole team …