I have a strange behaviour in Easy Chart component and also the DB. A totally empty SQLite DB's connection is established in the Gateway and it's valid in the status. I am using only one OPC tag to insert its values to the database with Tag Historian. The deadband style is "Analog" and without having issues, I am able to insert the data to the SQLite.
Sample Mode: Periodic
Sample Rate: 1 sec
When I do binding the data (with SQL Query) I get the values to the table component but the t_stamps seems incorrect, as you can see it below.
Assuming that this timestamp is in seconds : GMT : Tuesday, 20. May 2003 03:04:57 Your time zone : Tuesday, 20. May 2003 05:04:57 [GMT+02:00] Relative : 18 years ago
However if I do open the sqlite db file with DB Browser for SQLite software to visualize, I do see the correct values in t_stamp field, see below.
This is a very strange behaviour that I couldn't figure out. The tag belongs to the default group btw.
My second struggle to show Historian data in the Easy Chart component. As it is in the manual and also in the inductiveuniversity videos, I drag and drop the tag which has the historical data, but whenever I move the datetime selector it's only showing the last value, but not the history of the tag. So the line is always straight, not showing any difference but a flat line with different values. For the historian data, also the chart is not autorefreshing itself.
This is also same for realtime data.
Here is the screen shot of flat line:
I also tried to use DB pen in the Easy Chart customizer but there in the Time Column section it gives me error as t_stamp is not a date.
I doubt about it, because in the .sqlite database file, I do see the correct timestamps. (please, check the screenshot below). Also while I am feeding the Easy Chart component with the tag historian of this tag, it shows the correct datetimes in the chart itself. But only showing the straight line of the last value. Only making the “Named Query” gives me wrong t_stamp values, as it can be seen in the following ss. In the screenshot, you see on the right hand side, DB Visualization from another software and left hand side is the query that have been made within Designer.
Is your DB connection actually using the SQLite driver & translator type?
There was a bug (fixed well before 8.1.1) where SQLite’s lack of strict types caused precision loss in Java, so we special-case SQLite connections to pack values into long/double instead of int/float. What you’re experiencing looks like that.
Actually I had 8.0.12 today and I have upgraded Ignition to the latest stable one.
Driver Type: Generic
Default Translator: SQLITE
While I was checking the documentation for v8, I realised that the JDBC driver creates an empty SQLite database, if not exists in the given path. May this error because of the empty SQLite DB created by myself? I don’t think so, since I do not create any table, just raw sqlite file but I wanted to ask you
Also in the documentation the file extension is “.db” but in my case I have named it as “.sqlite”. Might that be the problem?
No, that shouldn't matter - a SQLite file is a SQLite file. Same for the file extension; we use .db as an entirely arbitrary convention.
I think the actual problem is that 'Generic' driver type; did you upgrade from an older version of Ignition? If I create a new DB connection using the SQLite type, it gets a SQLite driver type:
I'm not 100% on how the upgrade logic works, but (for testing) you could try disabling your current SQLite connection and making a new one - see if that uses the 'SQLite' driver type, and has the same issue when pointed to your existing file.
Actually, I checked the Databases ==> Drivers subsection to reply your previous message. When I check the connection subsection in the Databases, there it shows as you have it.
Hmm, I would say get in contact with support, at this point. It doesn’t look like anything obvious, but support should be able to help work through it.
I couldn’t get an answer from the support and I have tried it with postgreSQL. All working now without any problem. If anyone encounters this kind of problem, can try with another DB, such as postgreSQL.
