KI_START_ROW_BETWEEN
Argument | Enumeration | Purpose |
---|---|---|
handle | Handle | |
path | Path number | |
SYM(row1$)> | Row specifying starting key | |
nCols1 | Number of significant columns in a starting key | |
SYM(row2$)> | Row specifying end key | |
nCols2 | Number of significant columns in a ending 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_ROW_BETWEEN
This function is similar to KI_START_BETWEEN but it defines the initial and final key using the row buffers themselves, thus avoiding the use of KI_BUILD, and which can limit the columns in the result set if the initial row buffer was DIMmed using a DEFVIEW. Using a view can lead to significant performance improvements with SQL databases.
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. It was introduced with KCML 6.60.
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.