13.01.2013 Views

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Impact of MAX-ROWS<br />

Cursors<br />

The MAX-ROWS qualifier on a query determines the number of rows returned. The MAX-ROWS<br />

calculation is applied be<strong>for</strong>e any sorting is applied to the query, causing the results to be<br />

random. Consider the following example:<br />

DEFINE QUERY x FOR customer SCROLLING.<br />

OPEN QUERY x FOR EACH customer MAX-R0WS 15.<br />

GET LAST x.<br />

DISPLAY customer.custnum.<br />

REPEAT:<br />

GET PREV x.<br />

DISPLAY customer.custnum.<br />

END.<br />

When this example is run with the <strong>OpenEdge</strong> sports database, the first record return has<br />

custnum 54, and the repeat loop displays other custnums in descending order from there. When<br />

this example is run with the sports database migrated to MS <strong>SQL</strong> <strong>Server</strong>, the first record<br />

returned has custnum 15, and the repeat loop displays values in descending order from there.<br />

This difference in results is a caused by the MAX-ROWS being applied prior to the sorting.<br />

Block cursors<br />

Block cursors are available as a per<strong>for</strong>mance enhancement. They allow blocks of records to be<br />

bound and fetched together from a single database request, thus reducing the network overhead<br />

and minimizing record copies <strong>for</strong> ABL queries and finds, and minimizing record copies.<br />

Considering block cursors and firehose cursors<br />

Block cursors are the default behavior replacing look-ahead cursors <strong>for</strong> NO-LOCK queries that are<br />

processed on the server side. A NO-LOCK query is one that executes with the NO-LOCK lock<br />

condition attached to its ABL statement.<br />

Block cursors are the preferred choice to process NO-LOCK queries on the server side. However,<br />

server-side cursor processing is not the primary choice overall. Firehose cursors, providing<br />

optimum per<strong>for</strong>mance <strong>for</strong> NO-LOCK queries, surpasses the benefits of block cursors because they<br />

are client-based. For an in depth presentation of firehose cursors, see the “Firehose and Fast<br />

Forward-Only Cursors” section on page 4–5.<br />

Additional details about block cursor behavior<br />

<strong>Data</strong><strong>Server</strong> connections that run at the read uncommitted isolation level will also execute<br />

queries that specify the SHARE-LOCK condition as NO-LOCK queries and will also utilize block<br />

cursors <strong>for</strong> their result sets. You can shut off block cursor behavior and revert back to<br />

look-ahead cursors <strong>for</strong> NO-LOCK queries by setting the -Dsrv PRGRS_BLOCK_CURS,0. If you leave<br />

block cursors on but wish to turn off the block and/or look-ahead cursor optimizations <strong>for</strong> a<br />

specific query, you can set the QUERY-TUNING option QUERY-TUNING(NO-LOOKAHEAD) on your<br />

ABL statement.<br />

2–49

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!