OpenEdge Data Management: DataServer for Microsoft SQL Server

Chapter 2: Initial Programming Considerations
USE-INDEX and BY clause considerations
The BY clause offers greater programming flexibility than the USE-INDEX clause, and
should be used in most cases. If indexes are added or deleted, applications coded with
the BY clause only require a recompile to adjust to the index changes. Applications
coded with the USE-INDEX clause require code modifications to be current with the
index changes. If the index specified by a USE-INDEX clause is dropped, the code will
fail to compile until the code is modified. If there is a more efficient index than the one
specified in the USE-INDEX clause, it will not be selected by ABL and it is unlikely to be
used in the data source’s query plan.
Dummy indexes for sort order
You can add dummy index definitions to your schema holder independent of the actual
index definitions in your MS SQL Server data source to provide a sort order. These
dummy indexes can improve the readability of your ABL code. An index in the schema
holder need not match an index in the MS SQL Server data source. However, the
absence of an index definition in the data source can impact performance when you
retrieve data with selection on the dummy indexes.
Unique indexes
If your MS SQL Server data source tables have at least one unique index, they can be
used to support operations such as backward and forward scrolling and accurate
cursor positioning through the FIND CURRENT, PREV, and LAST statements. If a table
does not have a unique index, you can only scroll forward through its data.
If a MS SQL Server data source table does not have a unique index, you can designate
an index to serve as the unique index for the schema holder. An index that you
designate as unique in the schema holder must be unique with respect to the data in
the data source, otherwise you receive runtime errors. See Chapter 7, “The DataServer
Tutorial,” for instructions on using the Data Dictionary to designate unique indexes.
MS SQL Server data source views and result sets from stored procedures do not have
unique indexes. Just as for tables, you can use the Data Dictionary to create a unique
index in the schema holder based on fields in a view or result set so that you can
browse data accessed through views or stored procedures. For more information about
views, see the “MS SQL Server data source views” section on page 68.
Note: Do not change the designated ROWID key of a record while an application is
running. Suppose, for example, that custnum is a unique key and has been
designated the OpenEdge ROWID. If a user changes the value of custnum for a
customer from 1 to 111, other users receive an error message when they try
to access the record for customer 1.
Large key entry support
Updates in the OpenEdge database enable existing index key limits, currently set at
approximately 200 bytes, to be widened. For example, this enhancement will enable
databases with a block size of 4K or 8K to support a maximum index key of
approximately 2000 bytes. Also, the index key width expansion extends the maximum
key size supported in the OpenEdge client that can be used with databases exported
to foreign data sources.
When you are migrating OpenEdge keys to a foreign data source, the key sizes cannot
be larger than those supported by the foreign data source. Because the maximum
OpenEdge key size is data-source dependent, you should consider your target data
66 OpenEdge Data Management: DataServer for Microsoft SQL Server