OpenEdge Data Management: DataServer for Microsoft SQL Server

Firehose and Fast Forward-Only Cursors
Enhancements overview
Firehose cursors deliver a streamlined, unmanaged, client-side cursor-processing mechanism
for handling result sets from a DataServer query. When connection pooling is enabled, firehose
cursors are the default mechanism for handling read-only results. If a firehose cursor is denied
to an application, the DataServer first attempts to substitute a Fast Forward-Only (FFO)
server-side cursor with Auto-Fetch and Auto-Close attributes in its place. If the query cannot be
handled by a FFO cursor, the cursor is further downgraded.
Firehose cursors
Firehose cursors are identified in Microsoft SQL Server as the default result set. A default result
set is generated when the statement attributes of a cursor are left unchanged from their standard
MS SQL defaults. The default result set allows rows from a query result to be pulled without
locks in forward-only sequence into a client-side cache. The default result set is referred to as a
firehose cursor because it can “flood” the client with results. It is unencumbered by the cursor
management necessary with server-side cursors.
The following DataServer operations are eligible for the firehose cursor implementation:
• All NO-LOCK queries.
• All SHARE-LOCK queries with transaction isolation level set to read-uncommitted.
• Internal no-lock queries that populate the key cache for transaction-oriented operations.
• All stored procedure result sets.
• All send-sql-statement result sets.
• Queries written with the QUERY-TUNING(SEPARATE-CONNECTION) keyword. When
connection pooling is enabled, the QUERY-TUNING(SEPARATE-CONNECTION) is redundant.
Note: Prepared statements associated with firehose cursors are now cached on a statement
cache that is associated with the managed connection. Statement reuse may decrease
based on the recycling of managed connections. To completely disable the prepared
statement cache, use the following connection switch: “-Dsrv PRGRS_PREPCACHE,0”.
For information on monitoring the statement cache reuse, see the “Monitoring cursor
and connection use” section on page 4–6.
Firehose exclusions
Certain statements and fields automatically exclude a query from consideration for a firehose
cursor. Two examples are:
• FOR FIRST and FOR LAST statements. Because these statements return at most one row,
they are optimized with the Transact-SQL keyword TOP, which renders them ineligible for
a firehose cursor.
• Queries that include text or image fields that translate to SQL LONGVARCHAR and
LONGVARBINARY data types. If possible, use field lists to exclude these fields from your
result set.
4–5