KI_START_BEG
Argument | Enumeration | Purpose |
---|---|---|
handle | Handle | |
path | Path number | |
SYM(row$) | Optional row buffer specifying the view | |
maxrows | Max number of rows required | |
sql | SQL Where Handle | |
status | KDB_ERROR_ENUM | Return status |
KI_START_BEG
Sets the current sequential pointer to point before the first row of the rowset corresponding to the key path path. A subsequent KI_READ_NEXT will read the first row.
However, if path is negative, then the current pointer for the index ABS(path) is set to point after the last row on the key path. A subsequent KI_READ_NEXT for the same negative path will read the last row.
If the path is zero then the order is unspecified. It may follow an index path or it may be in the orders rows are laid out in the table. You can use a path of zero even if there are no actual indexes defined for the table.
The optional row buffer is no longer used and should be zero. The columns used in the SQL data base view will be taken from the columns in the row buffer passed to the first KI_READ_NEXT. The KI_START_BEG operation just logs the SQL that will be prepared and executed at the point of the first read.
The optional max_rows parameter can be used if you know you only want to read say the first row or, perhaps more commonly, the last row of a table. On an SQL database it gives the SQL optimizer more information about how it should perform the query and will avoid slow table scans. A missing or zero value implies that you don't know how many rows you will be reading. If you want to specify a max_rows value then pass zero as the SYM(row$) parameter.
The optional sql parameter can be used to pass SQL directly to the SQL database. The SQL passed here is inserted as part of any WHERE clause. To constuct the SQLHandle we need to use the #WHERE statement.
This function always succeeds if a table is open and the path corresponds to an actual index.
Compatibility
The optional row buffer argument was added and then deprecated in KCML 6.60 The maximum number of rows argument was introduced for KCML 6.60
The optional argument for SQL handle was introduced in KCML 7.07.