Skip to content

Introducing RowId

One of the major technology initiatives for DataFlex 11 is to make connecting to existing data much easier and more flexible. In the past, the database API/driver implementation required a numeric record identifier. This limited the possibilities to connect to existing data unless the table definition was modified to add a numeric identifier column if one was not already available.

We embarked on this initiative by defining our primary goal:

  • Make it possible to connect to more tables without needing to change those tables.

A number of secondary goals were also defined:

  • Existing applications must run unchanged with the embedded database.
  • Existing applications should run unchanged with other databases if we control the format of the tables.
  • Developers can connect to existing databases without needing to change table structure.
  • Developers can write new code, using the new syntax, that will work in either a recnum or non-recnum environment.
  • Multi-segment relationship support.
  • All DataFlex tools and packages will work in all environments.

The central concept to achieving these goals is the introduction of RowIDs.

DataFlex 11 Table Types

DataFlex 11 supports two types of tables:

  • Standard tables: where each row is uniquely identified by one or more columns of any type (this will almost always be the primary key).
  • Recnum-enabled tables: where each row is uniquely identified by a single column numeric identifier (such as those used in the embedded database and Pervasive.SQL).

A RowId is the data type that stores the unique identifier for a row. Applications can use it to store off record identifiers and to find records identified by the passed RowId. RowIDs can be used on both table types.

Note

The use of legacy row identifiers (recnum) in applications is still supported but can only be used with Recnum-enabled tables.

Manipulating RowIDs

RowIDs can be used for local and global variables, as properties, and in arrays (using the new array data type). All manipulation of RowIDs is done through RowId helper functions.

RowId is not just a simple replacement for RECNUM; they require a new style of programming. We refer to the two styles of programming as RowId and RECNUM styles. The RowId style will become the recommended style of programming because it works on all types of tables. The RECNUM style of programming only works with recnum-enabled tables.

Differences Between Programming Styles

Some of the differences between these styles are:

  • There is no explicit recnum column in a standard table. A standard table will not have a column 0.
  • Because there is no recnum column, you cannot move a value to it. This means that all of the RECNUM "tricks," such as moving 0 recnum to inactivate a buffer, cannot be used.
  • A standard table will not expose a recnum index (i.e., no index.0).
  • Attempts to use recnum or index.0 in a standard table will result in an error.

Do not confuse the style of programming (RowId or RECNUM - which specifies how you write your programs) with the type of table (standard or recnum-enabled - which specifies how your table is defined). The following shows how the programming styles and table type will interact.

Table Type RowId Style RECNUM Style
If Table Type is Standard Required Not Allowed
If Table Type is recnum-enabled Recommended Allowed / Legacy

Data Dictionaries and Programming Styles

There are DataDictionary messages that also used recnum references. These messages now have RowId counterparts. The new messages can be sent for both table types. The old messages can only be sent for recnum-enabled tables. The new messages are:

Be aware that in order to work with standard tables you must use RowIDs. In order to work with recnum-enabled tables, you can still use RECNUM, but it is also possible to use RowIDs. If you want your application code to work with both table types, you must change your code. To find out the required source code changes, you need to identify all places where you explicitly use RECNUM and change those to use RowId instead. This may be more complicated than simply replacing every reference to RECNUM with a reference to RowId. If, for example, RECNUM is passed as an argument, not only must the message be adjusted, but also all places that call the message. Next, you need to find all occurrences of DataDictionary recnum messages and replace them with the new RowId counterpart.

Multi-segment RowId Support

Standard tables support multi-segment, non-contiguous RowIDs. Since the columns comprising a RowId are used to define relationships, multi-column relationships are also supported. This removes the need for overlap fields.

Note

This change will be applicable to all table types, which means that a developer using the embedded database can take advantage of this feature.

New API Attributes Defined in FMAC

Product Changes in Support of RowIDs

All of the components of DataFlex, from the runtime to the documentation, have changed in support of RowIDs and the RowId style of programming.