Generally speaking, there are no requirements to change existing ABL applications when migrating to a table partitioned database. However, consider several issues when running an existing ABL application on a partitioned table:
The order in which records are returned may differ for a newly partitioned table.
A partitioned table must have at least one local index, which is based on the partition fields. When partitioning a table, you can make existing indexes local if they are aligned with the partition fields, but you may need or want to add a new index to satisfy the requirement for a local index. Anytime a new index is added to a table and you recompile, the new index may be used by queries that previously used a different index, and as a result, it is possible that the records will be returned in a different order than they were before.
Partition fields must be set before record creation.
By the time a physical record is created in the database, all of the partition fields must be set. A field is "set" either because the code explicitly assigns it a value or because the field has an initial value. The actual record creation does not happen on the CREATE statement. The creation often happens in the following cases:
The AVM is about to release the buffer, which can happen as a result of any of the following:
An explicit RELEASE or VALIDATE statement
The reading of a new record into the buffer
The record going out of scope
The end of the transaction
You set a LOB field.
You set a field that an index is based on.
The timing of the record creation is important in the case that the partition fields do not have initial values. If, for example, the AVM executes a CREATE statement and then immediately sets a field that an index is based on, an error occurs. This is because setting the field causes the underlying record creation to take effect, and at that point none of the partition fields have been set. An error also occurs at the end of a DO TRANSACTION block if there is a CREATE statement inside the block but not all of the partition fields are set.
ROWID values may change as a result of changes to a partition field.
In the past, an update to a record would never cause the ROWID of the record to change. Now, if the value of a partition field changes such that a record now belongs in a different partition, the record's ROWID will change because the ROWID identifies the location and partition of the record. If you store a ROWID value for some reason, the stored ROWID may need to be updated in this scenario.
ROWID values encapsulate partition information, but RECID values do not.
You cannot use a RECID value to identify the partition of a record in a partitioned table. Using a stored RECID value to retrieve a record in a partitioned table will not work unless the record is in the initial composite partition. However, the ROWID of a record in a partitioned table identifies the location and partition of the record. Applications that need to store and reuse record locations in partitioned tables should use ROWID instead of RECID.
When changing RECID functions or attributes to ROWID in your application, you should keep the following differences in mind:
A RECID value is an integer, whereas a ROWID value is a variable-length set of bytes.
You can display a RECID directly to the screen or store it directly to a file, but you cannot do so with a ROWID. You must first convert the ROWID value to a string (using the STRING function, for example).
Because RECID values are integers, you can compare them using greater than (with the GT or > operator) or less than (with the LT or < operator), but you cannot do the same with ROWID values. You can, however, check ROWID values for equality.
To retrieve partition information, a new function, BUFFER-PARTITION-ID, has been added. Two new attributes, BUFFER-PARTITION-ID and IS-PARTITIONED, have been added to the buffer object handle.
The order in which records are returned may differ for a newly partitioned table.