Mapping of Value and Status Data Input – A single PI tag can only historize or but never both together. Therefore, a value status, consistent method of mapping a given pair (SELECTed from an RDB table) into value/status the PI concept is provided. PI System interfaces mostly apply the following rule: If the of a is store the status value value. ‘good’, If the of a is other than store the instead. status value status ‘good’, Note: Any requirement that goes beyond that needs more than one tag. Previous sections of this manual demonstrate that the interface requires both and value status in the SELECT field list. The following paragraphs will explain how these two fields make it into various PI point types. Mapping of SQL (ODBC) Data Types to PI Point Types Data Input – In general, the following columns can appear in the SELECT list: TIMESTAMPn TAGNAMEn (see section ) VALUEn STATUSn ANNOTATIONn To be able to process the aforementioned fields, the interface makes some considerations for their data types. The following table shows what combinations of PI point types and SQL column data types (used in SELECT queries) are valid. Tags that do not match those criteria are rejected by the interface. This does not mean that those tags cannot be serviced at all. It only means that additional explicit conversion might be required. The following tables list the allowed RDB data types in combination with PI tag types: RDB Data Types to PI Point Types Mapping Value – Input Field SQL Data Type PI Point Type Timestamp SQL_TIMESTAMP All PI point types Tag name SQL_CHAR, All PI point types SQL_VARCHAR, SQL_LONGVAR CHAR Real(R) Integer(I) Digital(D) String(S) Value Approximate (floating Cast to the Cast to long Cast to Converted points) data types particular integer integer and from interpreted SQL_NUMERIC, type. as pointer to SQL_DECIMAL, to Digital string. SQL_REAL , State Set SQL_FLOAT, SQL_DOUBLE
Mapping of Value and Status – Data Input A single PI tag can only historize value or status, but never both together. Therefore, a consistent method of mapping a given value/status pair (SELECTed from an RDB table) into the PI concept is provided. PI System interfaces mostly apply the following rule: If the status of a value is ‘good’, store the value. If the status of a value is other than ‘good’, store the status instead. Note: Any requirement that goes beyond that needs more than one tag. Previous sections of this manual demonstrate that the interface requires both value and status in the SELECT field list. The following paragraphs will explain how these two fields make it into various PI point types. Mapping of SQL (ODBC) Data Types to PI Point Types – Data Input In general, the following columns can appear in the SELECT list: TIMESTAMPn TAGNAMEn (see section ) VALUEn STATUSn ANNOTATIONn To be able to process the aforementioned fields, the interface makes some considerations for their data types. The following table shows what combinations of PI point types and SQL column data types (used in SELECT queries) are valid. Tags that do not match those criteria are rejected by the interface. This does not mean that those tags cannot be serviced at all. It only means that additional explicit conversion might be required. The following tables list the allowed RDB data types in combination with PI tag types: RDB Data Types to PI Point Types Mapping – Value Input Field SQL Data Type PI Point Type Timestamp SQL_TIMESTAMP All PI point types Tag name SQL_CHAR, SQL_VARCHAR, SQL_LONGVAR CHAR All PI point types Real(R) Integer(I) Digital(D) String(S) Value Approximate (floating points) data types SQL_NUMERIC, SQL_DECIMAL, SQL_REAL , SQL_FLOAT, SQL_DOUBLE Cast to the particular type. Cast to long integer Cast to integer and interpreted as pointer to Digital State Set Converted from to string.
PI_RDBMSPI_3.21.4.30.docx