When the PI RDBMS Interface gets a bad timestamp from the source RDB that it cannot coerce into a PI Timestamp, the actual bad timestamp received from the RDB should be logged as part of the error message.

This would coincide with the following error:

"pitm_settime() error - 15002. Using current time."

Example:  When using a distribution tag, the number of tags returned and number of values sent to PI can be mismatched, due to missing aliases or data that does not need to be collected.

It would be helpful to identify what values are dropped or were not updated in PI.  While there is the @rows_dropped variable, it can only be used for distribution tags and may have limitations when used with stored procedures.

For whatever reason, times such as -1w or -1y are not accepted, but times such as -1mo and -1d are OK.

Please make the PI Interface for RDBMS accept the same relative times that other PI programs accept.

When the PI RDBMS Interface gets a bad timestamp from the source RDB that it cannot coerce into a PI Timestamp, the interface attempts to use the current timestamp instead and logs the following error:

"pitm_settime() error - 15002. Using current time."

The interface should instead include an option that controls what to do in this situation. The potential options would be to either discard the event entirely after logging an appropriate error or to use the current timestamp of when the event was retrieved (Also logging an appropriate warning).

We have encountered a situation where we were unable to write out-of-order data to PI through the buffer subsystem from an interface, apparently because the buffer subsystem was not yet fully initialized when the interface connected to it. Please implement an appropriate wait cycle at interface startup, to ensure that the buffer subsystem (on which the interface is dependent) is fully initialized and available before permitting the interface to complete its connection and initialization.

Note the case in question arose when the interface service was configured with a dependency on the PI Buffer Subsystem service.

Currently the ODBC connection is configured with a SQL date time parameter when retrieving the TS parameter (snapshot time stamp).
Due to the fact lots of sources system having more precision in their time stamps, it makes it hard to compair source time stamp to the pi time stamp (precision and rounding issue in SQL).
I request to add support for sql datetime2 into the ODBC connection, or an option to read the time from the snapshot in seconds since 1.1.1970

I have a scan-based output point writing multiple PI values to the relational database as described here:
https://livelibrary.osisoft.com/LiveLibrary/content/en/int-rdbms-v4/GUID-1A194D2B-388B-4FD7-8B82-D85EDDBBC572

I would like to perform history recovery for such an output point, but this is currently not possible because the output point is scan-based:
https://techsupport.osisoft.com/Troubleshooting/KB/KB01139/

Since event-driven tags can have only one source tags, I cannot recover historical data from multiple PI tags with only one output tag.

The PI Interface for RDBMS currently accepts the format dd-mmm-yy but not the format dd-mmm-yyyy for history recovery start and end times.

The former format lacks the century, so the year is ambiguous. The latter format solves this problem and so should also be accepted as a valid time format.

If you use IntrumentTag for the query, it has to be a file containing the query, not the query itself.
You can specify the actual query in Exdesc.