Remote Database Access

RDA is a communications protocol for remote database access that has been adopted as an International Standard by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It has also been adopted as an American National Standard by ANSI and as a Federal Information Processing Standard (FIPS) for the U.S. federal government.

RDA was published as a combined ANSI/ISO/IEC standard in 1993. It consists of two parts:

   Part 1  --  Generic RDA              ANSI/ISO/IEC 9579-1:1993
   Part 2  --  SQL Specialization       ANSI/ISO/IEC 9579-2:1993
Part 1 specifies the generic model, service, and protocol for arbitrary database connection and Part 2 specifies additional protocols for connecting databases conforming to Database Language SQL. Both Parts are available in hard copy only from ANSI (Sales telephone: +1-212-642-4900); Part 1 is 151 pages and Part 2 is 59 pages. Further extensions and enhancements are under development (see RDA ENHANCEMENTS below).

RDA is not published as a separate FIPS; instead, it is recognized as a separate conformance alternative in the FIPS for SQL, FIPS PUB 127-2 (see Section 14.4), and in the FIPS for SQL Environments FIPS PUB 193 (see Section 6).

RDA protocols are defined in terms of ASN.1 abstract syntax notation (ISO/IEC 8824:1987) and ASN.1 basic encoding rules (ISO/IEC 8825:1987). The ASN.1 definitions of RDA/SQL Specialization protocols are available for use by emerging RDA implementations.


Remote Database Access provides standard protocols for establishing a remote connection between a database client and a database server. The client is acting on behalf of an application program while the server is interfacing to a process that controls data transfers to and from a database. The goal is to promote the interconnection of database applications among heterogeneous environments.


The RDA standard provides an RDA Service Interface to an RDA Communication Element that exists both at the client site and at the server site. The RDA Communication Element converts RDA service requests into underlying ACSE and TP service requests as part of an open systems interconnection.

The RDA Service Interface consists of service elements for association control, for transfer of database operations and parameters from client to server, for transfer of resulting data from server to client, and for transaction management. Association control includes establishing an association between the client and server remote sites and managing connections to specific databases at the server site. Database operations are sent as character strings conforming to the SQL language. Resulting data and/or errors and exceptions are described and represented using the ISO ASN.1 standard. Transaction management includes capabilities for both one-phase and two-phase commit protocols.

The RDA standard describes RDA services in terms of an RDA Client, and RDA Server, and an RDA Service as follows:

     An RDA client is an application-process, within an open
     system, that requests database services from another
     application-process called a database server.  A database
     server is an application-process, within the same or another
     open system, that supplies database storage facilities and
     provides, through OSI communication, database services to RDA
     clients.  An RDA client and a database server communicate by
     means of the RDA Service, supported by an RDA service-
     provider.  The part of the database server that uses the RDA
     service-provider to communicate with an RDA client is called
     an RDA server.  The RDA client has the ability to initiate RDA
     service requests, while the RDA server can only issue RDA
     service responses to reply to such requests.

     A data resource is a named collection of data and/or
     capabilities on the database server known to both the RDA
     client and the RDA server.  The meaning of the data content
     and capabilities of a data resource depend upon the
     application of RDA, which is determined by each RDA
     specialization standard (e.g. the SQL specialization).  The
     RDA client opens a data resource in order to gain access to
     the data content or capabilities of that resource through
     Database Language services (e.g. SQL).  Data resources may be
     nested, with subordinate data resources grouped within their
     parent data resource.  The RDA client is required to open a
     parent data resource before it can open subordinate data

     An RDA transaction is a logically complete unit of processing
     as determined by the RDA client.  Execution during an RDA
     transaction of a sequence of database access services that
     change data resources enables the set of changes to be handled
     as an atomic unit.  When the RDA transaction is terminated,
     either the whole set of changes is applied to the data
     resources or no changes are applied.  The RDA client requests
     termination of an RDA transaction by requesting the RDA server
     either to commit or to roll back the complete set of changes
     of that transaction.  Changes made to the data content of data
     resources during an RDA transaction are not made available to
     other RDA clients until that RDA transaction is terminated at
     the RDA server.  RDA provides a choice of two application-
     contexts for managing RDA transactions: 1) a basic
     application-context for one-phase commitment, and 2) a TP
     application-context for two-phase commitment.  The RDA
     protocol for the basic application-context is completely
     specified in the RDA standard, whereas the protocol for the TP
     application context is dependent upon the ISO/IEC Distributed
     Transaction Processing standard (ISO/IEC 10026).

     An RDA operation models a request by an RDA client that is
     transferred to an RDA server for processing.  RDA operations
     enable an RDA client to request any of five types of RDA

           a)  RDA Dialogue Management services, to start and end
               RDA dialogues;

           b)  RDA Transaction Management services, to start and
               end RDA transactions;

           c)  RDA Control services, to report the status or
               cancel existing operations;

           d)  Resource Handing services, to enable or disable
               access by RDA clients to data resources;

           e)  Database Language services, to access and modify
               data resources.

     An RDA client may request RDA operations without waiting for
     the results of previously requested RDA operations.  Thus an
     RDA server may have several RDA operations outstanding for a
     particular RDA dialogue.

     An RDA dialogue is a cooperative relationship between and RDA
     client and an RDA server.  The RDA client initializes the RDA
     dialogue and requests RDA operations that are to be performed
     by the RDA server.  An RDA dialogue is uniquely identified
     within the scope of the OSI environment, and all RDA
     operations occur within the bounds of an RDA dialogue.  An RDA
     dialogue can exist only in the context of an established
     application-association, and ceases to exist if the
     association is released.  A failed RDA dialogue cannot be
     recovered; the process of recovery after a failure is a local
     matter beyond the scope of the RDA 1993 standard, and recovery
     actions outside the RDA service-provider may be necessary.  In
     the event of dialogue failure, it is a requirement that all
     changes made to data resources by any RDA transaction that is
     not already terminating when RDA dialogue failure occurs be
     rolled back by the database server during its recovery
     process.  If an RDA dialogue is terminating when RDA dialogue
     failure occurs, then it may either be committed or rolled
The OSE Implementor's Workshop (OIW) has specified implementation agreements for the Basic Application Context of the RDA standard, with profiles for: Immediate Execution, Stored Execution, Status, and Cancel. Future work is in progress by the OIW to specify corresponding profiles for the Transaction Processing (TP) Application Context. Only the Immediate Execution profile is required for all RDA conforming implementations; the other profiles of the Basic Application Context and the TP Application Context are optional enhancements to this basic requirement as follows:

RDA Stored Execution. Support for the Immediate Execution profile and, in addition, support for the RDA Stored Execution Functional Unit as specified in the RDA'93 standard.

RDA Status. Support for the Immediate Execution profile and, in addition, support for the RDA Status Functional Unit as specified in the RDA'93 standard.

RDA Cancel. Support for the Immediate Execution profile and, in addition, support for the RDA Cancel Functional Unit as specified in the RDA'93 standard.

RDA TP Application Context. Support for the Immediate Execution profile and, in addition, support for the RDA SQL TP Application Context as specified in the RDA'93 standard, and dependent upon ISO/IEC 10026 (Distributed Transaction Processing).


RDA is appropriate for remote access to a database in any context where lower layer transport protocols have already been established. RDA protocols have been shown to work properly in both OSI and Internet communications environments. The Internet RFC 1006 is the guide used for executing RDA over a TCP/IP connection.

It is expected that RDA will be used for interconnection among SQL database management products from different vendors. Interconnection among database products from the same vendor will likely continue to use vendor specific communication and interchange forms.


The existing RDA/SQL Specialization standard does not yet support all of the facilities in the SQL-92 (ISO 9075:1992) language standard. Instead, it more closely approximates support for just the Entry SQL level of SQL-92. Work is in progress on an Amendment 1 to the RDA/SQL Specialization to support all SQL-92 features. Expected progression dates for Amendment 1 are CD registration in 1995 and formal adoption as an International Standard by 1997.

SQL-92 data types not yet fully supported by RDA are: DATE, TIME, TIMESTAMP, INTERVAL, CHARACTER VARYING, NATIONAL CHARACTER, BIT, and BIT VARYING. Also, very long character and bit strings, e.g. blobs, are not yet fully supported. SQL-92 facilities for special Descriptor and Diagnostic areas are not supported implicitly in RDA. Amendment 1 to the RDA/SQL Specialization will provide data type encodings for the above types and may also include facilities for Descriptor and Diagnostics information to flow on each SQL statement. In most other cases, RDA simply carries an SQL statement from Client to Server, so additional RDA facilities are not needed.

return to SQL Table of Contents

For questions on SQL, RDA, and related standards, contact Len Gallagher (