When r-code runs each time a table, view, or buffer is opened, the DataServer checks the data definitions of the Oracle database to make sure they match the schema definitions in the schema holder. If they do not match, the DataServer returns an error.

Unmatched definitions can result in the corruption of your Oracle database. However, verifying the definitions is time consuming in a production scenario. In a production environment, you might consider using the -Dsrv skip-schema-check startup parameter to increase performance, but only when you are certain that the data definitions in the Oracle database, at least for the tables you are accessing, have not changed.

Even if you specify the skip-schema-check option, the DataServer does not skip the schema check if one of these cases is true:

• The schema holder does not have enough information on the table being queried to determine the maximum size of a column. In Version 8, the DataServer did not store information in the schema holder on maximum sizes of CHARACTER and RAW columns, and a migrated schema holder might not have this information. For example, there might not be maximum size information if you migrated a Version 8 schema holder that you dumped and loaded into a Version 9 schema holder and then forward to an OpenEdge 10 schema holder. To make sure that the schema holder has the required maximum size information, use the Update/Add Table Definitions utility, found on the OpenEdge Oracle Utilities > DataServer > Data Administrationmenu, to update the schema holder after using the dump and load utilities.
• A view does not have a field selected to serve as a record identifier (PROGRESS_RECID).

The dataserv.lg log file notes when the DataServer skips the schema check.

Measure carefully the performance benefit against the risk to your database before deciding to use -Dsrv skip-schema-check.