Additional details about block cursor behavior
- Last Updated: February 11, 2026
- 3 minute read
- OpenEdge
- Version 13.0
- Documentation
DataServer connections that run at the read uncommitted
isolation level will also execute queries that specify the SHARE-LOCK condition
as NO-LOCK queries and will also utilize block
cursors for their result sets. You can shut off block cursor behavior
and revert back to look-ahead cursors for NO-LOCK queries
by setting the -Dsrv PRGRS_BLOCK_CURS,0.
If you leave block cursors on but wish to turn off the block and/or
look-ahead cursor optimizations for a specific query, you can set
the QUERY-TUNING option QUERY-TUNING(NO-LOOKAHEAD) on
your ABL statement.
While block cursors increase efficiency, they might also require
more memory than look-ahead cursors. Block cursors will try to reuse
memory from previous result sets whenever possible. You can adjust
the memory available to block cursors according to your specifications.
Adjust the cache size of an individual block with the same connection-level
parameter you used to set the look-ahead cache size. The -Dsrv QT_CACHE_SIZE option
allows you to specify at connect time how large the block cache
should be for individual query results. When block cursors are active,
the default QT_CACHE_SIZE is set to 10,000 bytes.
When look-ahead cursors are active, this size defaults to 30,000
bytes.
Use the parameters to set the number of Dataserver connections for the read-only queries when
run on the server. By setting the suitable connections for your application can increase the
performance of the application. Than following -Dsrv is to set the managed connections
-Dsrv RGRS_CACHE_CONN,n. Here ‘n’ is the number of connections. Let
Dataserver to run the ABL queries like JOINs or stored procedures in separately connections by
setting the switch -Dsrv QT_SEPARATE_CONNECTION improve the application
performance.
You can override the connection-level QT_CACHE_SIZE at
the statement level by setting the QUERY-TUNING option
called CACHE-SIZE on the query itself. Determining
the proper block size should be based on the maximum length of your
returned records multiplied by the expected number of resultant
rows and then compared to your available memory. Whenever an existing
block is not reused, the block of memory allocated for the query
will be adjusted downward to an exact multiple of the number of
rows that can fit into the allocated area.
To prevent large applications from potentially overutilizing
memory for block cursors, two other settings can be adjusted to
limit the amount of memory available to block cursors. The first
is the maximum block memory usage per table. If you have multiple
queries open against the same table simultaneously, each query uses
its own query block. The -Dsrv PRGRS_TABLE_BLOCKSIZE option
puts an upper limit on the total memory available to query blocks
of an individual table. This number should normally be set larger
than the QT_CACHE_SIZE value. It can be set as
high as two or three times the QT_CACHE_SIZE. If
the maximum block memory available to the table will be exceeded
by allocating space for the current NO-LOCK query
in your ABL, the query is instead executed with a look-ahead cursor.
The default maximum block memory area per table is set at 65,000
bytes.
The second adjustment switch available is the -Dsrv PRGRS_MAX_BLOCKSIZE option.
This value sets an upper limit to the overall memory provided to
block cursors, irrespective of per table allocations. The default
maximum is 1048576 bytes (or 1MB). Your accumulated total memory
allocated for block cursors will not exceed this value. If allocating
block cursor memory for a NO-LOCK query in your
ABL will cause this limit to be exceeded, the query would instead
be executed with a look-ahead cursor. The PRGRS_MAX_BLOCKSIZE value
should be set with respect to the amount of memory available on
your machine. If you are running in client-server mode, the number
should be set with respect to both the available memory on the server
machine as well as the number of clients that will be connecting.
The following example uses the state table in the demo database, which has a maximum record size of 84 bytes:
|
In this example, the QUERY-TUNING CACHE-SIZE value
overrides the -Dsrv QT_CACHE_SIZE query block
size default of 10,000 bytes. Ten records at 84 bytes per record
totals 840 bytes in the query block. If a previously established
block is located for that table that is greater than or equal to
the requested size, it will be reused. However, if a new block is
established instead, its memory allocation will be adjusted downward
to 840 bytes in order to fit an exact multiple of rows in the block.
Then, if the result set contains 30 records, the query block will
get refilled three times before the end of the result set if read
sequentially.