Consultor Eletrônico

Status: Unverified

GOAL:

What dictionary changes force recompiling?

GOAL:

How do database changes impact OpenEdge 10 ABL procedures or classes?

GOAL:

What schema changes require code to be recompiled?

GOAL:

When does the CRC for database objects change?

GOAL:

Is it required to recompile the application after changing the database schema?

FACT(s) (Environment):

OpenEdge 10.x
All Supported Operating Systems

FIX:

First, WHY would schema changes require code to be recompiled ?

The OpenEdge client ensures that the program running only has references to database objects (Tables, Indexes and LOBs) for which the definitions have remained unchanged since the last compile. This prevents ungraceful runtime errors and writes to the database with internal inconsistencies, which could occur if the software tried to address a non-existent or unrecognized data structure.

This is done by storing CRC values for tables and indexes into the compiled code. (LOB fields are calculated into the table CRC).
For tables, the CRC is stored if there is a static reference to the table or one of it's fields in the code. This value will be compared with the structure of the database(s) at run time to verify the connected database has the same structure in place as the database(s) at compile time.
For indexes, the CRC is stored if the index is used by a static QUERY, FOR EACH or FIND construct. This can be explicitly specified with a USE-INDEX option, but more commonly this is determined implicitly by the compiler. In the second case, the SEARCH entries in the XREF listing will indicate which indexes the code uses.

When an r-code file is loaded at runtime, the CRC's stored in the r-code are checked against the CRC's stored in the currently connected databases (which do not have to be the same as the ones connected at compile-time). If the CRC's do not match at that time, the code will not be executed.

NOTE:
- Referencing a table does NOT include using the LIKE option to define variables, temp-tables or temp-table fields based on dictionary entries.
- Dynamic objects working on the database (dynamic buffers, queries and related constructs) are handled at runtime only, and do not cause any CRC values to be stored at compile time even if the object names are hard-coded. This includes the shorthand notations (For example: "<buffer handle variable>::<buffer-field name>").
- In contrast, a dynamic reference to a static buffer will require recompiling if the schema changes (For example: "BUFFER customer:FIND-FIRST()" ).


So, WHICH schema changes require code to be recompiled ?

The following changes will affect the table CRCs and will therefore require the code to be recompiled.

For tables:
- Changing the name of the table or index
- Deleting a field in the table
- Added a field to the table
- Changing the field order within the table

For table fields:
- Changing the name, data type, decimal precision, number of extents or case sensitivity
- Changing foreign database metadata in a schema-holder database for Dataservers (foreign database field type, length, offset, or case sensitivity)

For indexes:
- Changing the index name, uniqueness requirement or abbreviated option.
- Adding, removing or changing the order of the indexed fields
- Changing the ascending/descending order of an indexed field


NOTE:
In OpenEdge 10.1C and later, to provide better support for online schema changes on the client side there are 3 exceptions to these rules when connecting an OpenEdge client to an OpenEdge database.

In these cases the table CRC changes, but the client will continue to execute the code compiled against a previous version of the schema without requiring a recompile:
- Added a field to the table
- Changing the field order within the table
- Changing the decimal precision on a table field


Which schema changes do NOT REQUIRE recompiling but may affect the code ?

The OpenEdge Dictionary includes many features that, in effect, provide defaults for functional application code. Any change to one of these items will NOT force a recompile of the object code, and will not change the table's CRC.
However, it is important to remember if you do NOT recompile .the code, the change WILL NOT TAKE EFFECT. In most cases, if changes are made in these areas a recompile is reccommended.

These features will be written to the compiled program at compile time, and will not be updated from the database at runtime.
For example, if you have added data validation statements or made security changes, the old code continues to allow updates without enforcing the new validation and the new security is not in effect. These application-oriented changes are:

- Adding, changing or removing validation expressions and messages of a table or it's fields.
- Adding, changing or removing schema triggers of a table or it's fields.
- Adding, changing or removing security settings of a table or it's fields.
- Changing the description of a table or it's fields.
- Changing the initial value, case sensitivity, or mandatory requirement of a field in the table.
- Changing the format, label, column-label or help message of of a field in the table.

Other changes that do not force a recompile:
- Adding new indexes to an existing table. (Existing static code will simply not use the new index, even if it would benefit from it. Dynamic constructs will be able to use them as these determine index usage at runtime.)
- Adding a new table and its associated fields. (Again, static code would need to be modified to use the new table anyway. Dynamic code may be able to see and work with these tables, depending on how it's written.)


Which schema changes do NOT REQUIRE recompiling and will not affect the code ?

The database offers features to manage the physical storage of the tables, the memory management, the support of SQL connections etc. A number of these features are configured through the schema definitions.
However, the ABL client only cares about the logical layout of the table, so any changes made to these features have no impact at all on the r-code. These features include, but are not limited to:

- Moving object to a different storage area
- Configuring the object to use an alternate buffer pool (10.2B and up)
- SQL field width/field format.