OpenEdge Data Management: DataServer for Microsoft SQL Server

Database design issues
For example, migrating data to a MS SQL Server 2000 database will need to be limited to a wide
key capacity of 900 bytes due to the 900-byte key restriction imposed by the foreign data source.
Case sensitivity
By default, an OpenEdge database is case insensitive. An MS SQL Server database is also case
insensitive by default. Using case insensitivity in both OpenEdge and MS SQL Server enables
seamless compatibility between the two, and provides the best performance, and least
maintenance. However, you can set the attributes of a field to define it as either case sensitive
or case insensitive. If you intend to use case sensitivity, consider the following:
• Pattern-matching literals in data source access statements retrieve case-sensitive data.
• The OpenEdge database considers the user ID and password submitted at connection time
to be case sensitive.
If an indexed field is case insensitive, an OpenEdge database does not distinguish between
uppercase and lowercase letters for that index when sorting or matching data. In general, this
flexibility in an application makes data entry easier for end users because they can enter
lowercase or uppercase versions of an index. However, if you want to enforce an
uppercase/lowercase distinction in your applications, set the attribute to case sensitive.
If you are using a case sensitive code page, the DataServer can make this feature compatible
across OpenEdge and MS SQL Server data sources. To support case insensitivity with a case
sensitive code page, an extra column, known as a shadow column, must be added to the data
source immediately before the indexed column. This column is named _S#_column. See the
“Migrating an OpenEdge database to MS SQL Server” section on page 7–20 for instructions on
adding this column automatically with the OpenEdge DB to MS SQL Server utility.
Note: By default, sort order in MS SQL Server is not case sensitive.
Interaction of code page, collation, and case sensitivity
Properly setting code page, collation, and case sensitivity values such that they compliment
each other, will yield the best scenarios for data access. To avoid conflict between code page,
collation, and case sensitivity, set these characteristics at schema creation, and allow a schema
pull to manage the DataServer integration. If any of these settings are changed, the schema
holder should be regenerated. Table 2–3 describes the interaction between code page, collation,
and case sensitivity.
MS SQL Server data source views
MS SQL Server data source schema objects include views. A view is a presentation of data in
one or more tables. Views appear as tables, not as views, in the Data Dictionary’s table list for
the schema holder. In addition, the schema holder contains no unique index information for
views. Because views do not have unique indexes, you cannot modify any of the data that a view
contains; however, you can access a view with the FOR EACH, FIND NEXT, and GET NEXT
OpenEdge statements. Furthermore, because views do not have index definitions, the
DataServer cannot reposition the cursor to retrieve individual records. Thus, you must be sure
to get all of the data that you need in a single database request.
2–13