And some wierd thing happened.
The mysql database contains 23997 rows of tag data.
Bith the designer and vision client now is suuuuuuuuper slow and consume alot of cpu.
Saving the project can take 30 minutes (tried rebooting several times)
Did you check the ‘Retain Rows’ checkbox on the binding that populates the data on this table?
Does your script still look just like what you originally posted, or have you made further changes?
Generally slow behavior means there’s either something holding up the event dispatch thread (which is where configureCell has to run, so you must make sure to avoid ‘slow’ operations like tag reads or DB operations) or there’s an extremely large dataset being saved into the Vision window (which unchecking ‘Retain Rows’ avoids).
SELECT sqlt_data_1_2021_11.t_stamp, sqlt_data_1_2021_11.stringvalue, sensor.tagText AS SensorText, ecodes.errortext FROM sqlt_data_1_2021_11
inner join sensorid Sensor ON sensor.tagID = sqlt_data_1_2021_11.tagid
inner join ecodes ON sqlt_data_1_2021_11.stringvalue = ecodes.errorcode
WHERE stringvalue != "0000"
This filters out 99.99999% of the data since most records are “0000” and only leaves me with errorcodes, that the joins translates to a sensor and errorcode with text from the help file matching the ID’s
EDIT: Now i got to find a way to convert the t_stamp to actual date/time, the from_timestamp in mysql doesnt work for example.
Its not for production, its only to look for problems on my desk plc, so i caneasilly just change with table i want to look at for the day, trying to find a reason behind the random modbus time outs im getting, and thought to use the tag history in educational purpose.