KI_START_BETWEEN
Argument | Enumeration | Purpose |
---|---|---|
handle | Handle | |
path | Path number | |
key1$ | Starting key | |
cols1 | Number of significant columns in the starting key | |
key2$ | End key | |
cols2 | Number of significant columns in the end key | |
max_rows | Max rows to return | |
bLock | Lock result set | |
bSkipMatch | Skip matching row | |
sql | SQL Where Handle | |
status | KDB_ERROR_ENUM | Return status |
KI_START_BETWEEN
This function is similar to KI_START, but limits the rows to be returned to have their key values greater or equal to key1$ and less than or equal to key2$.
The cols1, cols2 and max_rows parameters give the same behaviour as the corresponding parameters in KI_START. Setting a column count to zero implies that all of the columns will be used from the appropriate supplied key and setting it to -1 implies that none of the columns will be used and thus that end of the range will be open. When determining how to start the result set, if cols1 is non-zero then only those columns will be matched and missing columns will be considered to be ALL(00). Similarly in determining the upper limit key, if col2 is non-zero non-significant columns will be assumed to be ALL(FF).
If the optional bSkipMatch flag is set to TRUE then the first rows in the result set are not returned if they match the supplied key. For positive path values a subsequent KI_READ_NEXT will read the first row with a key greater than the supplied key. For negative path values a subsequent KI_READ_NEXT a subsequent KI_READ_NEXT on the same negative path will read the last row with a key less than the supplied key.
Compatibility
This function is only available for KDB type 7 and SQL database tables.
Prior to KCML 6.60 the direction for the result set was deduced from the ordering of the keys and path was assumed positive. As of KCML 6.60 the direction comes from the sign of path and the ordering of the keys is always low then high.
KCML 6.60 introduces a KI_START_ROW_BETWEEN which works from row buffers and which has extra functionality.
It was common practice with KDB to make columns insignificant by setting them to ALL(00) or ALL(FF), depending on direction. Because HEX(FF) is not a legal UTF-8 character this may cause problems with SQL databases and is the practice is strongly deprecated. See connection attributes for information about how the _KDB_CONN_ATTR_KEY_PADDING attribute can be used to control how padding is handled.