There are four new features in
OpenEdge 10.1B and later that can cause incompatibility with previous OpenEdge 10 releases:
- Databases can now grow so that rowids will require more than 32-bits of significance.
- The new INT64 datatype, especially when it is the datatype for a database column.
- Database sequences are no longer limited to a maximum of 2GB.
- 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:
“One 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 this database is accessed with a 10.1B executable before this is done, an error message that instructs that the bi file needs truncating with the 10.1A PROUTIL utility. The same applies for 10.0A and 10.0B databases, their bi files need to be truncated with the pre-10.1B PROUTIL version.
Once the 10.1A database has been accessed for the first time with a 10.1B executable, (PROSERVE, PROUTIL, PROBKUP, PRO 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. Sequences will still be 32-bits, INT columns will still be limited to 32-bits of significance and indexed columns will still be limited to a maximum length of 192 bytes regardless of whether the client is 10.1A or 10.1B.
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 of 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: PROUTIL dbname -C enableseq64
- For INT64 columns: Access the Database Dictionary and change INT columns to INT64 columns.
- For INT64 columns on VSTs: PROUTIL db-name -C updatevst
- For large index keys: Either access the Data Administration tool > Admin > Enable large key Entries or PROUTIL db-name -C enablelargekeys
Features that are enabled on the database can be queried through the
PROUTIL -C DESCRIBE functionality. For example:
Database Features
ID Feature Active Details
---- -------------------------- ------ -------
9 64 Bit DBKEYS Yes
10 Large Keys Yes
11 64 Bit Sequences Yes
What happens to 10.1A clients when these features are enabled? For 64-bit sequences, nothing happens until a 10.1A client actually references a sequence whose value will not fit into a 32-bit integer. When it does the database server will not 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
and the client will exit generating a core dump and a stack trace on its way out:
The total length of the fields in an index exceeds max key size. Index <index-name> of table <table-name> (129) (11353)
SYSTEM ERROR: fillkey: error formatting existing key. (127)
There is nothing we can do to prevent this system error. 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. Defect PSC00178408 / OE00132685 was fixed in OpenEdge 10.1A02 where the 10.1A02 client will rollback the transaction when the key too large error occurs instead of core dumping and exiting.
When a database is created as an OpenEdge 10.1B database what features are enabled? All of them. The 10.1B default feature enablement are determined by what is enabled in the 10.1B empty databases. In addition, 10.1A clients that connect to this database then have the compatibility issues described above because all of them are enabled.
In SummaryOnce 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 malfunction immediately in any way. In this sense 10.1B/10.1A compatibility has been maintained. Only once a table grows beyond 2 billion rows, the DBA explicitly enables one or more of the above features could a 10.1A client begin to malfunction in some way.
