Products Support Documentation Download
Defunct Features

Set Implementation and Ordering

The internal representation of sets has changed. The version 12 implementation uses database addresses to point directly to first-member/last-member/next/previous/owner records. This allowed for manipulation of the order of the members when connecting them into a set. For example, if a set is declared as "order next" it connects the current record to follow the current member.

The v14 implementation of sets is done through indices. This has many advantages, especially if the set is naturally sorted or if it is large.

But with indexed sets, it is not possible to support unsorted orderings like next, prev, first or last. A migrated database may display set members in a different order than the original database. There are various ways to deal with this, most of which require changes to your application source code.

Core DDL

Core DDL is the original C-like data definition language implemented for RDM. Starting with version 10 of RDM, SQL DDL has also been supported by converting it into Core DDL and compiling that. However, v14 has a very tight inter-operation between Core and SQL, and they share a common data dictionary based on a common DDL. This common DDL is the SQL DDL.

This is why a step above requires the utility rdm-convert to process a .ddl file and create a .sdl (SQL DDL) file. Nearly everything that could be defined in Core DDL can be defined in SQL DDL. Having one common DDL simplifies many things for the RDM programmer. However, some of the Core DDL features are no longer implemented from within the SQL DDL. These will be explained in more detail below, but include optional keys and multi-member sets.

Optional Keys

Optional keys are declared "optional" in the DDL, and allow the application to control which rows will be included in an index. With the DDL now being specified as SQL DDL, there is no way to specify that a key in an index will be stored only if the application requests it.

Deprecated Functions

Some Core API functions have proven themselves to be less than useful over the years. One such function is d_makenew(). It will not be found in RDM , and can be replaced by d_fillnew().

Since optional keys are no longer supported, the d_keystore() and d_keydel() functions will return eDEFUNCT error codes.

System Record

Old-school network model DBMSs contained a System Record, which was always the current record just after opening the database. It could be the owner of sets, having the effect of creating global indices on those sets. With the RDM implementation of keys that don't require sets, the usefulness of a System Record is negligible. It is no longer possible to define one in v14.

Multi-Member Sets

A multi-member set was defined in Core DDL as having one owner type and multiple member types. Its main purpose was to implement variability in the data fields in the members. For example, member record types could have a string field of 10, 100 or 1000 bytes long, so that when a string was 2325 bytes long, it could be stored in a set containing members with 1000, 1000, 100, 100, 100, 10, 10 and 10 bytes long. With RDM v14, variability is built into the strings, and it is no longer necessary to break down and re-assemble strings or blobs from fixed-length records.


Both mirroring and replication have been removed from the first release of v14 in order to re-introduce a richer, more reliable set of data distribution features in a future minor release.