Row-count is a four-byte unsigned integer field that specifies the maximum number of rows to return in the response buffer. A value of zero imposes no row limit. When specified before a request is initiated, subject to the control of the Change-option option, it limits the rows returned in each response buffer until the value is changed. When specified in the DBCAREA before a Fetch function the Change-options option is not relevant, and the value will limit the rows in a response buffer obtained by that Fetch. If a Fetch function returns an unfetched parcel from an existing response buffer, no new response buffer is obtained and the DBCAREA Row-count value has no effect. To achieve the desired effect, an application changing Row-count before a Fetch must understand the relationship of parcels to buffers. A response buffer may contain multiple parcels; all parcels in a buffer are returned by Fetch one at a time before the next response buffer of parcels is requested from the database; if the Two-response-buffers option is 'Y', the default, then the next response buffer is filled before it is needed. Since exactly when such buffer prefilling is done is not under application control, a Two-response-buffers option of 'Y' is not recommended when a using non-zero Row-count.
Row-count does not affect the results of an SQL request, only the packaging of the results in response buffers.
|In this language...||The variable name for Row-count is...|
|This routine...||Does this for Row-count...|
|DBCHCL||reads (RSUP; FET; IRQ; IWPF)|
|Row-count is used by...||To...|
The default value is 0.
When Row-count is used with multi-statement requests, the rows from different statements are never combined into one response buffer. So the last response buffer for each statement may contain fewer rows than requested.
When a non-zero Row-count is specified, the Two-response-buffers option should probably be set to 'N' because 'Y' is used to maximize fetching performance while Row-count is used to reduce it.