The CONSISTENCY and CONCURRENCY options control the extent to
    which the database protects the consistency of your data.

    The broadening of isolation level support in Oracle Rdb V4.2 changed
    the way that Oracle Rdb treats RDO, RDBPRE, and RDML applications
    that use CONCURRENCY transactions. With Oracle Rdb V4.1 and earlier
    databases, these applications ignored the CONCURRENCY setting by
    running their transactions at the default CONSISTENCY setting.
    With Oracle Rdb V4.2 and later databases, the transactions are run
    at the CONCURRENCY setting specified.

    Because Oracle Rdb V4.2 expanded the CONCURRENCY setting in the
    START_TRANSACTION statement of RDO, your DBA should check those
    RDO, RDBPRE, and RDML applications that specify the CONCURRENCY
    keyword in START_TRANSACTION statements to ensure that the
    applications return expected results at the reduced consistency
    level defined by the CONCURRENCY setting.

    Your RDO, RDBPRE, and RDML applications that explicitly specify
    CONCURRENCY in START_TRANSACTION statements will now operate in
    Oracle Rdb V4.2 and later versions at the equivalent (SQL)
    ISOLATION LEVEL READ COMMITTED (formerly called CONSISTENCY
    LEVEL 2) when attached to either non-Oracle Rdb databases
    or Oracle Rdb V4.2 and later databases. Those RDO, RDBPRE, and
    RDML applications that do not explicitly specify a consistency
    level or explicitly specify CONSISTENCY (default) will not change
    transaction behavior.

    In pre-Oracle Rdb Version 4.2 releases, Oracle Rdb ran application
    transactions at the CONCURRENCY setting against non-Oracle Rdb
    databases only and ignored the CONCURRENCY setting when
    attached to Oracle Rdb databases. Instead of running these latter
    applications at CONSISTENCY LEVEL 2 (CONCURRENCY), as you might
    expect, Oracle Rdb ran them at the default CONSISTENCY LEVEL 3.

    For Oracle Rdb Version 4.2 and later versions, however, RDO, RDBPRE,
    and RDML applications that use the CONCURRENCY (CONSISTENCY
    LEVEL 2) setting in transactions attached to Oracle Rdb Version
    4.2 and later databases will no longer automatically revert
    to CONSISTENCY LEVEL 3 as was true in Oracle Rdb Version 4.1
    and earlier releases. Instead, they will run at the specified
    CONCURRENCY (CONSISTENCY LEVEL 2) setting.

    Refer to the "Differences in Relational Terminology" table in the
    "Terminology" subtopic of the DECRDB topic in the DCL help file
    for the relationship between SQL isolation level terminology and
    its equivalent RDO, RDBPRE, and RDML terminology.

    You can use the Oracle Rdb RDMS$DEBUG_FLAGS logical "T" option to
    determine the consistency level at which your executable images
    are running. The "T" option displays application transaction
    characteristics and will display TPB$K_DEGREE2 for those
    applications that use the CONCURRENCY option.

    Because some 4GL's also use CONCURRENCY, you should contact
    your 4GL vendor about possible changes in transaction behavior;
    however, Rdb expects that in most cases the CONCURRENCY
    option reflects how your DBA wants transactions to run and also
    that your DBA understands that the reduced isolation level should
    not be detrimental to applications.

    In other database systems that you might want to access using
    the remote feature of Oracle Rdb, this option specifies the degree
    to which you want to control the consistency of the database. In
    such systems, the CONCURRENCY option sacrifices some consistency
    protection for improved performance with many users.

    If you use the CONCURRENCY option, you may be able to transport
    your programs to another system that takes advantage of that option
    and achieve improved performance.

    The default for Oracle Rdb is CONSISTENCY. When CONSISTENCY is
    specified, Oracle Rdb always guarantees degree 3 consistency. Degree
    3 consistency means that the database system guarantees that
    data you have read will not be changed by another user before you
    issue a COMMIT statement.