Timestamp Error

I just started getting these errors for 8 different OPC timestamp variables.
All the tags are of Data Type DateTime.
There are new errors every 2 seconds.
I’m not sure what the cause of it is, can anyone help?

I’m running Ignition 7.7.0
I’ve tried restarting the Gateway PC but it had no effect.
The tags seem to be working correctly, it’s just that the error appears in the log console.


Hi David,

Not sure I can help, but maybe some more information can help narrow things down for more knowledgeable people.

Are all these using the same driver?

Are you reading the tag from the device or are you writing to the device?

Which Java version are you using?

This looks like a bug in the “exposed tags” feature. I’ll dig a little bit and see if this was fixed between 7.7.0 and 7.7.4.

What kind of tags are these?

Thanks for your help. I’ve upgraded to version 7.7.4 and the error has gone.

I’ll answer your questions anyway, just in case you’re still interested:
At least some of the tags were Query Tags, but I don’t know if all of them were since the errors have gone. They were all being read.
Java Version is 1.8.0_25. I guess I should also update this.

Kevin,

It looks like we're experiencing a similar issue with 7.7.5. Is is possible that the fix that went in between 7.7 and 7.7.4 was reverted back?

The issue appears in sqlTags of DateTime type. A db query writes an oracle Date column value to the tag. The tag then appears to return an object type of java.sql.Timestamp using system.tag.read().


Example of python:

lineNumber = "LINE1"
sql = "SELECT start_time FROM event_table WHERE line = ?"
parms = [lineNumber]
results = system.db.runPrepQuery(sql, parms)

for row in results:
startTime = row["START_TIME"]
system.tag.write("SITE_A/AREA/LINE1/StartTime")

value = system.tag.read().value
print str(type(value))

Returns:

<type 'java.sql.Timestamp'>

Regards,
Jeremy

[quote="jkiffer"]Kevin,

It looks like we're experiencing a similar issue with 7.7.5. Is is possible that the fix that went in between 7.7 and 7.7.4 was reverted back?

The issue appears in sqlTags of DateTime type. A db query writes an oracle Date column value to the tag. The tag then appears to return an object type of java.sql.Timestamp using system.tag.read().


Example of python:

lineNumber = "LINE1"
sql = "SELECT start_time FROM event_table WHERE line = ?"
parms = [lineNumber]
results = system.db.runPrepQuery(sql, parms)

for row in results:
startTime = row["START_TIME"]
system.tag.write("SITE_A/AREA/LINE1/StartTime")

value = system.tag.read().value
print str(type(value))

Returns:

<type 'java.sql.Timestamp'>

Regards,
Jeremy[/quote]

Jeremy,

This seems to be a different part of the system, but you shouldn't be having a problem because java.sql.Timestamp is a subclass of java.util.Date.

Kevin,

This can affect python code that compares two times. An implicit compare of two date objects will always return false. I also wanted to make sure there aren’t other implications.

We are in process of upgrading from 7.5.6. I was able to audit the DateTime sqltags on both versions (7.5.6, 7.7.5) and check the types returned. The 7.5.6 version always returns java.util.Date, whereas Ignition 7.7.5 at some point assigns the java.sql.Timestamp type.

Example of python code that can be affected if object types are as follows:
cachedTime <type ‘java.sql.Timestamp’>
newTime = <type ‘java.util.Date’>

Then:
cachedTime != newTime always returns True, even when the times are the same

I realize now that there are better ways to do the comparison that works:
cachedTime.getTime() != newTime.getTime()
-OR–
cachedTime.equals(newTime)

Just a heads up that this could break python codes that compares date and times. If nothing else then this will result in our developers writing better python code.

Thanks,
Jeremy

Something may have changed in the Oracle JDBC driver that is resulting in a java.sql.Timestamp being returned.

I think your best bet is to use on of the workarounds you already found - either compare the underlying long value or use the equals() method.