MAX ROWS

Specifies maximum number of rows that the SQL driver will attempt to fetch for every SQL statement sent to the server. This includes schema inquiry queries that the driver sends to the server during a table open to retrieve column, index, and valcheck information.

If a request is made for more than MAX ROWS, then an error is returned (DBIERR_ROWFETCHLIMIT). A return of DBIERR_ROWFETCHLIMIT is similar to DBIERR_EOF, except that it indicates a client-forced EOF when there actually may be more rows available on the server.

You can use the MAX ROWS option as a system governor to prevent users from unintentionally tying up valuable system resources. For example, a database administrator may set up users' configuration files to prevent them from tying up server and network resources if they happen to do a "SELECT * ..." on a huge table. You can set the MAX ROWS option make it impossible for a user to generate a million record query by mistake.

Be aware that if you set MAX ROWS too small, you may not be able to open a table under that database because it cannot get sufficient schema information. If MAX ROWS is not set to a large enough value to retrieve all the required metadata information during table open, then an error is returned and the table cannot be opened. MAX ROWS does not affect non-updateable queries in this way because a DESCRIBE (instead of a schema query) is used to get query column information.

Default:

-1 (No limit on fetching rows.)

Warning!

A MAX ROW limitation could break existing BDE applications that fetch until receiving DBIERR_EOF. Such applications must be modified to handle a return of DBIERR_ROWFETCHLIMIT as well as DBIERR_EOF. Users should be able to "see" all rows that have already been fetched, but they should be notified that there may be additional rows on the server.