Transaction group database write failure resulted in successful transaction

I made a historical transaction, and messed up a datatype in the PLC on accident, which resulted in the timestamp not being in the correct format for the database.

So when the transaction group went to store that data in the database, it got an error saying the value for that column wasn’t valid. Makes sense.

But transaction groups still wrote back a successful handshake back to the PLC, and didn’t flag the execution as failed. Isn’t that the point, so that if the data doesn’t get successfully written to the database, it throws a flag and writes a failed handshake?

I did find the error in the logs, which is as it should be:

> DatasourceForwardTransaction	26Sep2018 20:00:13	Error forwarding data
> java.sql.BatchUpdateException: Data truncation: Incorrect datetime value: '659147-09-02 21:53:54.0' for column 'PLC_TimeStamp' at row 1

> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

> at java.lang.reflect.Constructor.newInstance(Unknown Source)

> at com.mysql.cj.util.Util.handleNewInstance(

> at com.mysql.cj.util.Util.getInstance(

> at com.mysql.cj.util.Util.getInstance(

> at com.mysql.cj.jdbc.exceptions.SQLError.createBatchUpdateException(

> at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchSerially(

> at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchInternal(

> at com.mysql.cj.jdbc.StatementImpl.executeBatch(

> at org.apache.commons.dbcp.DelegatingStatement.executeBatch(

> at com.inductiveautomation.ignition.gateway.datasource.DelegatingStatement.executeBatch(

> at com.inductiveautomation.ignition.gateway.datasource.SRConnectionWrapper$SRStatement.executeBatch(

> at com.inductiveautomation.ignition.gateway.history.BasicHistoricalRecord.storeToConnection(

> at com.inductiveautomation.ignition.gateway.history.sinks.RecordDatasourceSink.storeDataToDatasource(

> at com.inductiveautomation.ignition.gateway.history.sf.sinks.AbstractDatasourceSink.storeToDatasource(

> at com.inductiveautomation.ignition.gateway.history.sf.sinks.AbstractDatasourceSink.storeData(

> at com.inductiveautomation.ignition.gateway.history.sf.sinks.AggregateSink.storeData(

> at

> Caused by: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Incorrect datetime value: '659147-09-02 21:53:54.0' for column 'PLC_TimeStamp' at row 1

> at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(

> at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(

> at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(

> at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchSerially(

Here’s the status window of the transaction afterward:

So I’m wondering, why did transaction manager handle this as though it were successful? How can I simulate a bad transaction that actually would say failed?

The ‘Handshake’ for successful execution is somewhat misleading with default transaction group settings - since in the Advanced options, groups default to using Store and Forward. Thus, a “good” handshake is returned once the group has given its data to the (asynchronous) store and forward system. To guarantee an accurate handshake, you need to disable store and forward for the group.