The following Help topics describe the usage of system tables
    with respect to particular versions of Oracle Rdb or in table to
    other database constructs, operations, or products.

1  –  Using Data Dictionary

    Although you can store your data definitions in the data
    dictionary, the database system refers only to the system
    tables in the database file itself for these definitions. In a
    sense, the system tables are an internal data dictionary for the
    database. This method improves performance as Oracle Rdb does not
    have to access the data dictionary at run time.

2  –  Modifying

    When you create a database, Oracle Rdb defines, populates,
    and manipulates the system tables. As the user performs data
    definition operations on the database, Oracle Rdb reads and
    modifies the system tables to reflect those operations. You
    should not modify any of the Oracle Rdb system tables using data
    manipulation language, nor should you define any domains based on
    system table fields. However, you can use regular Oracle Rdb data
    manipulation statements to retrieve the contents of the system
    tables. This means that your program can determine the structure
    and characteristics of the database by retrieving the fields of
    the system tables. See the Example Help subtopic under System_
    Tables in this Help library for an example of querying system
    tables.

3  –  Updating Metadata

    When you use the SQL SET TRANSACTION . . . RESERVING statement
    to lock a set of tables for an Oracle Rdb operation, you normally
    exclude from the transaction all the tables not listed in the
    RESERVING clause. However, Oracle Rdb accesses and updates system
    tables as necessary, no matter which tables you have locked with
    the SQL SET TRANSACTION statement.

    When your transaction updates database metadata, Oracle Rdb
    reserves the system tables involved in the update in the
    EXCLUSIVE share mode. Other users are unable to perform data
    definition operations on these tables until you complete your
    transaction. For example:

    o  When you refer to a domain (global field) in an update
       transaction that changes data definitions, Oracle Rdb locks
       an index for the system table, RDB$RELATION_FIELDS. No other
       users can refer to the same domain until you commit your
       transaction.

    o  When you change a system table or domain definition, Oracle
       Rdb locks an index in the system table, RDB$FIELD_VERSIONS. No
       other users can change table or global field definitions until
       you commit your transaction.

    o  When you change a table definition, Oracle Rdb locks an index
       in the system table, RDB$RELATION_FIELDS. No other users can
       change tables in the same index node until you commit your
       transaction.

4  –  LIST OF BYTE VARYING Metadata

    Oracle Rdb has supported multiple segment LIST OF BYTE VARYING
    data types for user-defined data. However in previous versions,
    Oracle Rdb maintained its own LIST OF BYTE VARYING metadata
    columns as single segments. This restricted the length to
    approximately 65530 bytes. An SQL CREATE TRIGGER or CREATE MODULE
    statement could fail due to this restriction.

    This limit was lifted by changing the way Oracle Rdb stores its
    own metadata.

    o  For columns containing binary data, such as the binary
       representation of query, routine, constraint, trigger action,
       computed by column, or query outline, Oracle Rdb breaks the
       data into pieces that best fit the system storage area page
       size. Thus, the segments are all the same size with a possible
       small trailing segment.

       The LIST OF BYTE VARYING column value is no longer fragmented,
       improving performance when reading system metadata.

    o  For columns containing text data such as the SQL source
       (for elements such as triggers and views) and user-supplied
       comment strings, Oracle Rdb breaks the text at line boundaries
       (indicated by ASCII carriage returns and line feeds) and
       stores the text without the line separator. Thus, the segments
       are of varying size with a possible zero length for blank
       lines.

       An application can now easily display the LIST OF BYTE VARYING
       column value and the application no longer needs to break up
       the single text segment for printing.

    No change is made to the LIST OF BYTE VARYING column values
    when a database is converted (using the RMU Convert command, RMU
    Restore command, or SQL EXPORT/IMPORT statements) from a previous
    version.

    Applications that read the Oracle Rdb system LIST OF BYTE VARYING
    column values must be changed to understand multiple segments.
    Applications that do not read these system column values should
    see no change to previous behavior. Tools such as the RMU Extract
    command and the SQL SHOW and EXPORT statements handle both the
    old and new formats of the system metadata.