Accepted Solutions
Hi Matt,
You need to assign a value to the ID_LENGTH to identify the fields used as the Key (to make each row unique). To use all fields in that row, you could set the ID_LENGTH to 80.
This is discussed in the online help under 'Defining a Record':
ID_LENGTH
This represents the size in bytes of the collective set of fields that uniquely identify each record instance, that is, the 'Key' fields.
Key fields start from the field containing the START_ARRAY token and include each following field until their accumulated length matches the ID_LENGTH value. For example, a record with an ID_LENGTH of 4 has two Key fields, each one with a TYPE value of BINARY_16 (i.e. 2 bytes each).
The maximum ID_LENGTH value is 640 bytes. An ID_LENGTH of 0 is valid as this means that there are no key fields and therefore only a single row of data for the record will ever be delivered at a time.
ID_LENGTH must be an even number of bytes and must be the accumulated size of all Key fields (taken from the TYPE value of each field). For this reason, it is recommended to define the fields that are to form the key FIRST. If this value is not set to the exact total size of the fields that make up the key the following message will be displayed.
"Record ID length is not at boundary defsrec:<nnn>:<record_name>".
Where <nnn> is the line number of the record definition in error and <record_name> is the name of the affected record."
TIMESTAMP and RESPONSE_TIME fields are 12 bytes long, not 8 as you might guess from looking at their definition. See details in the DISPLAY_OPTION section of the Defining a Field topic. In designing a unique key, it is necessary to consider that the key must continue to be unique over time. For example, at any point in time, a running process on a machine might be uniquely identified by a PID or process ID. However, over time, processes stop and start and PIDs get re-used, so a key of PID by itself is not sufficiently unique for use as the key of a Prognosis process record. A compound key of (PID, ProcessStartTime) would be a good solution. If the key is not unique data will be lost.
Hi Matt,
You need to assign a value to the ID_LENGTH to identify the fields used as the Key (to make each row unique). To use all fields in that row, you could set the ID_LENGTH to 80.
This is discussed in the online help under 'Defining a Record':
ID_LENGTH
This represents the size in bytes of the collective set of fields that uniquely identify each record instance, that is, the 'Key' fields.
Key fields start from the field containing the START_ARRAY token and include each following field until their accumulated length matches the ID_LENGTH value. For example, a record with an ID_LENGTH of 4 has two Key fields, each one with a TYPE value of BINARY_16 (i.e. 2 bytes each).
The maximum ID_LENGTH value is 640 bytes. An ID_LENGTH of 0 is valid as this means that there are no key fields and therefore only a single row of data for the record will ever be delivered at a time.
ID_LENGTH must be an even number of bytes and must be the accumulated size of all Key fields (taken from the TYPE value of each field). For this reason, it is recommended to define the fields that are to form the key FIRST. If this value is not set to the exact total size of the fields that make up the key the following message will be displayed.
"Record ID length is not at boundary defsrec:<nnn>:<record_name>".
Where <nnn> is the line number of the record definition in error and <record_name> is the name of the affected record."
TIMESTAMP and RESPONSE_TIME fields are 12 bytes long, not 8 as you might guess from looking at their definition. See details in the DISPLAY_OPTION section of the Defining a Field topic. In designing a unique key, it is necessary to consider that the key must continue to be unique over time. For example, at any point in time, a running process on a machine might be uniquely identified by a PID or process ID. However, over time, processes stop and start and PIDs get re-used, so a key of PID by itself is not sufficiently unique for use as the key of a Prognosis process record. A compound key of (PID, ProcessStartTime) would be a good solution. If the key is not unique data will be lost.
