The ROWID data type provides a unique record identifier that is compatible across OpenEdge and MS SQL Server databases. Applications that use the ROWID function behave in the same way whether they access records in an OpenEdge databases or in a MS SQL Server data source. The ROWID function is more consistent than RECID across data sources, since RECID cannot guarantee uniqueness. Progress Software Corporation recommends that you replace the RECID function with ROWID in existing applications.

The DataServer supports the ROWID function for MS SQL Server data source tables that have a unique index. The DataServer utilities use an index that meets this criterion to provide values for the ROWID function. If you build your schema holder using the OpenEdge DB to MS SQL Server utility and you select the Create RECID fieldoption, it is automatically designated as the ROWID index. However, if you do not create the RECID field, you can select a unique index to support ROWID. See Defining the ROWID for instructions.

Note: Starting with OpenEdge Release 10.1B, the default external representation of ROWID enables the MS SQL Server Dataserver to use a 64-bit integer value for ROWID. Using an integer value to define ROWID is not required, but rather an option to efficiently represent ROWID as a numeric binary value. The MS SQL Server DataServer supports the INT64 data type to emulate ROWID expansion support in this use.

The ROWID value in a MS SQL Server data source differs from the ROWID value in an OpenEdge database if you use the unique index method in the following ways:

  • In an OpenEdge database, you can create a ROWID without creating a record. In DataServer applications, creating a ROWID creates a record. The following statement illustrates the difference in behavior:
    CREATE customer.
a = ROWID(customer).

    The DataServer creates a customer record using default values.

  • The ROWID changes if the value of the unique keys in the designated index changes.
  • The DataServer considers a single instance of the Unknown value (?) to be unique, so it is possible to have a ROWID with the Unknown value (?). However, the OpenEdge ROWID function fails if you search for an Unknown value (?), because an OpenEdge ROWID will never have the Unknown value (?). For example, the following FIND statement fails even if there is a row with the Unknown value (?) in the designated column:
    FIND customer WHERE ROWID(customer) EQ ?.
  • If you force the creation of a record before entering the value for the designated column (for example, by committing a transaction or releasing or validating a record), the creation fails if the column cannot have NULL values. If the column can have NULL values, the DataServer assigns the new record a ROWID of NULL. However, if the column has an initial value, the DataServer creates the row with that initial value as the ROWID.

Follow these guidelines when using ROWID in applications that you want to deploy across multiple OpenEdge databases and/or MS SQL Server data sources:

  • Do not try to get a record's ROWID value before the user assigns values to the unique keys of the record.
  • Refresh the ROWID value if a value of a unique key might have changed.

    Refresh the ROWID value after you undo a DELETE. The ROWID value might be different after the record is recreated.

  • ROWID values are stable for a session, but you cannot rely on them to be the same across sessions.
Note: Reposition functions such as REPOSITION-BACKWARDS and REPOSITION-TO-ROW typically use ROWID to identify records. Functions of this type require integer expressions, which can be either INTEGER or INT64.

For a complete description of the ROWID function, see its reference entry in OpenEdge Development: ABL Reference.