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.

Additional Features to Enhance <strong>Data</strong><strong>Server</strong> Per<strong>for</strong>mance<br />

Join by <strong>SQL</strong>DB<br />

4–14<br />

For queries that include joins issued in FOR EACH and OPEN QUERY statements, the <strong>Data</strong><strong>Server</strong><br />

evaluates the queries and in some cases instructs the MS <strong>SQL</strong> <strong>Server</strong> data source to per<strong>for</strong>m the<br />

joins. A join per<strong>for</strong>med by the data source, called a join by <strong>SQL</strong>DB, can improve per<strong>for</strong>mance;<br />

however, you receive the associated query results in an order consistent with the data source,<br />

not with the <strong>OpenEdge</strong> database. To get results that are consistent with the <strong>OpenEdge</strong> database,<br />

turn off JOIN–BY–<strong>SQL</strong>DB, either with the QUERY–TUNING phrase at the query level or with the<br />

<strong>Server</strong> Join (-nojoinbysqldb) startup parameter when you compile. If the order of returned<br />

records is important to your application, specify a sort order on the query.<br />

For each join, the <strong>Data</strong><strong>Server</strong> evaluates whether the MS <strong>SQL</strong> <strong>Server</strong> data source can per<strong>for</strong>m it<br />

and estimates whether doing so improves per<strong>for</strong>mance. To determine whether a join by <strong>SQL</strong>DB<br />

is possible, the <strong>Data</strong><strong>Server</strong> assesses whether the following criteria are true:<br />

• All tables in the join are in the same logical <strong>OpenEdge</strong> database; that is, they are contained<br />

in the same <strong>Data</strong><strong>Server</strong> schema.<br />

• Every table, except the innermost one, has a unique record identifier (ROWID or RECID<br />

support).<br />

• The query does not include a USING phrase <strong>for</strong> any of the inner tables. For example, a join<br />

by <strong>SQL</strong>DB will not occur <strong>for</strong> this query:<br />

FOR EACH customer, EACH order OF customer USING order.ordernum:<br />

• The query does not include a BY phrase that contains expressions or array fields.<br />

• The query does not include a request <strong>for</strong> an EXCLUSIVE-LOCK on any of the tables in the<br />

join.<br />

• The join does not exceed 10 levels.<br />

To estimate whether per<strong>for</strong>ming a join by the data source might improve per<strong>for</strong>mance, the<br />

<strong>Data</strong><strong>Server</strong> assesses whether these additional criteria are true:<br />

• The join uses an OF clause or a WHERE clause <strong>for</strong> each of the inner table loops. For example,<br />

the following query requires a field-to-field correspondence between two tables:<br />

FOR EACH customer, EACH order OF customer:<br />

• The WHERE clause includes either an operator or the AND option. The following example<br />

includes the equals (=) operator:<br />

FOR EACH customer, EACH order<br />

WHERE customer.custnum = order.custnum:<br />

The <strong>Data</strong><strong>Server</strong> also per<strong>for</strong>ms a join by <strong>SQL</strong>DB <strong>for</strong> the following query:

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

Saved successfully!

Ooh no, something went wrong!