Possible to know if write to database succeeded?

We have data that must reach the database. If a write to the database fails, we need to know this on return from the call, so that we can take appropriate action.

When calling a method that modifies the database, is there any way to get confirmation on return from the call that the data has in fact been added to the database?

For us, an acceptable answer may be, “Yes, if you bypass the store and forward system, in this manner…”

Can you use the “getkey” from this?

https://docs.inductiveautomation.com:8443/display/DOC/system.db.runPrepUpdate

I don’t know. My understanding is that updates to a database are loosely coupled, meaning that the system call will return before the record has passed through the store and forward system and arrived at the database.

It would seem that specifying getKey=1 forces the runPrepUpdate call to wait for the record to arrive at the database, so that the generated key value can be returned.

This would only apply to insertion of a new record, I think. An update of an existing record would not generate a new key.

Through what API will this interaction with the database take place?

I’m not sure I can name all of the available APIs. At this point, we’re in discovery mode.

I was thinking primarily of calls that originate in a module, but we’re keeping an open mind about using Jython in a project.

In my test module, I’m using SRConnection.runQuery to read records. I was expecting to call one of the non-select methods to insert and update.

In a project Jython script, there are the system.db methods.

Perhaps it is also possible to use JDBC objects to access a database?

Also: It may be sufficient to know that the data has been successfully written to the hard drive cache on the gateway. I’m supposing that in the event the gateway PC crashes, upon restart of the gateway the records in the hard drive cache will be forwarded to the database.

Unless you are explicitly running your DB access through the HistoryManager API it does not involve the S&F system, so for all other database access when the call returns you can assume the data has been written (as far as any DB client can be concerned. What the DB does with the data is beyond the scope).

Hooray!
This is a big deal for us.