Consultor Eletrônico

Status: Verified

GOAL:

Summary of compatibility rules for 10.1B and earlier OpenEdge versions.

GOAL:

Can 10.1A clients connect to a 10.1B database

GOAL:

what are the implications of a pre 10.1B client connecting to a 10.1B database

GOAL:

considerations when upgrading the databse to verions 10.1B

FACT(s) (Environment):

All Supported Operating Systems
Progress/OpenEdge Versions

FIX:

There are four new features in OpenEdge 10.1B and later that can cause incompatibility with previous OpenEdge 10 releases:

1. Databases can now grow so that rowids will require more than 32-bits of significance.
2. The new INT64 datatype, especially when it is the datatype for a database column.
3. Database sequences are no longer limited to a maximum of 2GB.
4. The length of the data in a set of columns used as an index on a table may now be up to 1972 bytes long, compared to the previous limit of 192 bytes.

Each of the above features has its own compatibility rules. There is no single set of compatibility rules that covers them all. To see what happens with these various features consider the following scenario -

A customer has existing databases and installs OpenEdge 10.1B.

The bi file of the existing databases needs to have been truncated with the 10.1A proutil utility. If they attempt to access this database with a 10.1B executable before this is done they will get an error message that says they need to truncate the bi file with their 10.1A proutil utility. This also applies for 10.0A and 10.0B.

Once the 10.1A database has been accessed for the first time with a 10.1B executable, (proserve, proutil, probkup etc) a silent conversion to 10.1B occurs. From this point onwards, this database can no longer be accessed with a 10.1A executable, unless that client connects to the database in client/server mode.

What does this silent conversion enable by default? Only the ability of a database table to grow beyond 2 billion rows. Their sequences will still be 32-bits, their INT columns will still be limited to 32-bits of significance and their indexed columns will still be limited to a maximum length of 192 bytes regardless of whether the client is 10.1A or 10.1B.

So what happens if a table in the database grows beyond 2 billion rows and a 10.1A client accesses that table? As long as the client does not access that part of the table beyond the 2 billion row boundary - nothing happens. But if it attempts to a create a row in such a table the server will disconnect the client and put a message in the .lg file for the database saying the 10.1A client was disconnected because it referenced a "large rowid" that it cannot handle. If the client attempts to read a row above the 2 billion row limit it will be similarly disconnected. The 10.1A client just gets told it has been disconnected from the database, the reason for it can only be seen from the .lg file for the database.

To upgrade a database that originated before 10.1B so that it has 64-bit sequences, INT64 database columns, or large index keys the dba has to explicitly enable those features:
- For 64-bit sequences: use the proutil db-name -C enableseq64 command.
- For INT64 columns: go into the dictionary and change one or more of their INT columns to INT64 columns.
- For INT64 columns on VSTs: use proutil db-name -C updatevst command.
- For large index keys they must use either the proutil db-name -C enablelargekeys command or the data administration tool > Admin > Enable large key Entries.

The features that are enabled on the database can be queried through the: proutil dbname -C describe command. For example:

Database Features
ID Feature Active Details
---- -------------------------- ------ -------
9 64 Bit DBKEYS Yes
10 Large Keys Yes
&.nbsp; 11 64 Bit Sequences Yes

What happens to 10.1A clients when each of these things is enabled? For 64-bit sequences nothing happens until a 10.1A client actually references a sequence whose value won't fit into a 32-bit integer. When it does the database server won't return the value to the client but rather will disconnect it, putting the reason for the disconnection in the database .lg file. If the dba changes an existing INT column into an INT64 column this will change the CRC value for the table: existing rcode will have to be recompiled before the table can be referenced again.

If the dba enables large keys then a 10.1A client will not have a problem until it encounters a row that has values in the row such that when those values are composed into an index key string that string exceeds 192 bytes. A client composes a key string from the values in the row when it needs to create a new row, delete a row or update a column in a row that is indexed. If they try and create a row with a larger than 192 byte key string, then the 10.1A client will enforce the old limit even though large keys have been enabled for the database. Still in the case of creates the client won't get a SYSTEM ERROR.

However if the client either updates a column whose data exceeds the old key size limit or attempts to delete such a row they will get the following error: "SYSTEM ERROR: fillkey: error formatting existing key. (127)" and the client will exit generating a core dump and a stack trace on its way out. There is nothing we can do to prevent this system error. The bug# 20060920-041 has been entered for this issue. The 10.1B server has no ability to detect at runtime that it is returning a row that the 10.1A client may have a problem with, as it does for large rowids or 64-bit sequences.

When a customer's database is created as a 10.1B database what features are enabled? All of them. And since all of them are enabled then 10.1A clients that connect to this database have the compatility issues described above. The 10.1B defaults are determined by what is enabled in the 10.1B empty databases.

In summary, once 10.1B is installed and used with a 10.1A database there are no features automatically enabled that could cause remote 10.1A clients to immediately malfunction in any way. In this sense 10.1B/10.1A compatibility has been maintained. Only once a table grows beyond 2 billion rows or the dba explicitly enables one or more of the above features could a 10.1A client begin to malfunction in some way.
.