The SQL'92 standard [8] specifies three different binding styles: Module, Embedded SQL, and Direct Invocation. The RDA'93 standard [9] specifies protocol interfaces for RDA clients and RDA servers, and an emerging standard for the SQL call level interface (SQL/CLI) is under a rapid development path in ISO/IEC with final approval as a new International Standard expected sometime during calendar year 1995. The following subsections describe how an SQL/ERI Server may claim conformance to an SQL/ERI profile using one of these interface alternatives.

6.1 SQL Module processor

An SQL/ERI Server may provide a Module binding style to application programs. If a user creates a {module} according to the Format and Syntax Rules of Clause 12, "Module", of the SQL'92 standard, and if the {module} satisfies the restrictions of a given level of SQL for a given programming language, then the SQL/ERI Server shall process that {module} as an input text file and shall produce a binary output file that can be linked to the compiled output of any application program written in the programming language identified by the {language clause} of the {module}. The {module} output file shall abide by whatever restrictions are required for cross-language procedure calls by the operating system and processing platform for which Module binding support is claimed.

6.2 Embedded SQL preprocessor

An SQL/ERI Server may provide an Embedded SQL binding style to application programs. If a user creates an {embedded SQL host program} according to the Format and Syntax Rules of Clause 13, "Embedded SQL", of the SQL'92 standard, and if the {embedded SQL host program} satisfies the restrictions of a given level of SQL for a given programming language, then the SQL/ERI Server shall process that {embedded SQL host program} according to the General Rules and other requirements specified in the SQL'92 standard. An SQL/ERI Server may compile the entire {embedded SQL host program} to produce an executable file, or it may produce a conforming program, P, written in the language identified by the {language clause} of the {embedded SQL host program} and an implicit (maybe not actual) module, M, both as specified by Syntax Rules 13 through 15 of Subclause 19.1, "{embedded SQL host program}", of the SQL'92 standard. If the user compiles program P with a standard conforming programming language compiler designed for the operating system and processing platform environment for which Embedded SQL support is claimed, then the compiled version of P and an implementor-dependent version of M shall be linkable in that processing environment to produce an executable file that executes correctly according to the SQL'92 standard.

6.3 Direct invocation of SQL statements

An SQL/ERI Server may provide a Direct Invocation style of binding according to the requirements of Clause 20, "Direct invocation of SQL", of the SQL'92 standard. This binding style is very difficult to write conformance tests for because there is no "standard" way to capture data returned as the result of a query. Instead, conformance to this binding style requires a subjective evaluation of the results by a human user. For this reason, among others, the FIPS SQL standard [3] does not recognize Direct Invocation as the sole conformance alternative of an SQL implementation. Instead, it allows Interactive Direct SQL as a conformance option in addition to a Module or Embedded binding style.

For an SQL/ERI Server it makes more sense to recognize the Direct Invocation binding style as a viable conformance alternative. There are many situations, e.g. electronic bulletin boards, where a user may desire to send an SQL statement to an SQL/ERI Server and have the data results displayed on a screen or dumped into a human readable text file. For these reasons, the SQL/ERI Server profiles specified in Section 7 below do recognize Direct Invocation as a valid conforming interface style.

If a user creates a {direct SQL statement} according to the Format and Syntax Rules of Clause 20, "Direct invocation of SQL", of the SQL'92 standard, and if the {direct SQL statement} satisfies the restrictions of a given level of SQL, then the SQL/ERI Server shall process that {direct SQL statement} as input text and shall display the results, if any, in a human readable form on some sort of display device. For SQL/ERI Servers providing access to multimedia data, the display device may include a sound system, motion picture display, or even some form of virtual reality. The only real requirement is that a reasonable conformance testing authority be able to decide, subjectively, whether or not the {direct SQL statement} was properly executed.

If a {direct SQL statement} is a {direct select statement: multiple rows} that returns only character string or numeric data in the result rows and columns, then the SQL/ERI Server shall provide a user option to redirect the output of the query into a human readable text file. In this context, human readable means formatted so that a reasonable conformance testing authority can readily distinguish rows and columns and easily read the data. All numeric data returned as text shall be in the form of a valid SQL {signed numeric literal}, unless some explicit user action results in its being cast into some other form, e.g. Money with currency symbols attached. The SQL/ERI Server may use General Rules 5a, 5b, 6a, and 6b, of Subclause 6.10, "{cast specification}", of the SQL'92 standard, for additional guidance in casting numeric values into numeric literals.

Other requirements for the Direct Invocation binding style are as follows: if a statement raises an exception condition, then the SQL/ERI Server shall display a message indicating that the statement failed, giving a textual description of the failure; if a statement raises a completion condition that is a "warning" or "no data", then the SQL/ERI Server shall display a message indicating that the statement completed, giving a textual description of the "warning" or "no data"; an SQL/ERI Server that supports null values shall provide some implementation-defined symbol for displaying null values and, for character string values, this symbol must be distinguishable from a value of all {space}s. Preferably, the SQL/ERI Server will provide an implementor-defined method for a user to specify how null values shall be displayed, e.g. SET NULL AS '*'; however, this SET feature is not really needed if, instead, the SQL/ERI Server supports the NULL alternative in the {cast operand} of the {cast specification}.

6.4 SQL call level interface (SQL/CLI)

An SQL/ERI Server may provide an SQL Call Level Interface binding style according to the requirements of the emerging standard for SQL/CLI [10]. We expect the SQL/CLI specification to be formally approved as an ANSI/ISO/IEC standard sometime during calendar year 1995, in time for any future NIST testing of SQL/ERI Server profiles.

The call level interface is a requirement for third-party software developers who produce "shrink-wrapped" software for use on personal computers and workstations. They do not wish to use a Module processor or an Embedded SQL preprocessor binding style because they do not wish to distribute any source code with the products they sell to individual users. Instead they desire a services call interface to SQL data repositories that can be invoked from the calling environment provided by the host operating system. The calls to the SQL data repository can then be embedded in the object code just like calls to any other system service.

The Call Level Interface is an alternative mechanism for executing SQL statements. Reference [10] states that the SQL/CLI consists of a number of routines that:

• Allocate and deallocate resources.

• Control connections to SQL-servers.

• Execute SQL statements using mechanisms similar to Dynamic SQL.

• Obtain diagnostic information.

• Control transaction termination.

• Obtain information about the implementation.

Each allocated SQL-environment has an attribute that determines whether output character strings are null terminated by the implementation. The application can set the value of this attribute by using the routine SetEnvAttr and can retrieve the current value of the attribute by using the routine GetEnvAttr.

The Connect routine establishes an SQL-connection. The Disconnect routine terminates an established SQL-connection. Switching between established SQL connections occurs automatically whenever the application switches processing to a dormant SQL-connection. The ExecDirect routine is used for a one-time execution of an SQL-statement. The Prepare routine is used to prepare an SQL-statement for subsequent execution using the Execute routine. In each case, the executed SQL-statement may contain dynamic parameters.

The interface for a description of dynamic parameters, dynamic parameter values, the resultant columns of a dynamic select statement, and the target specifications for the resultant columns is a CLI descriptor area. A CLI descriptor area for each type of interface is automatically allocated when an SQL-statement is allocated. The application may allocate additional CLI descriptor areas and nominate them for use as the interface for the description of dynamic parameter values or the description of target specifications by using the routine SetStmtAttr. The application can determine the handle value of the CLI descriptor area currently being used for a specific interface by using the routine GetStmtAttr. The GetDescField and GetDescRec routines enable information to be retrieved from a CLI descriptor area. The CopyDesc routine enables the contents of a CLI descriptor area to be copied to another CLI descriptor area.

When a dynamic select statement is prepared or executed immediately, a description of the resultant columns is automatically provided in the applicable CLI descriptor area. In this case, the application may additionally retrieve information by using the DescribeCol routine to obtain a description of a single resultant column and by using the NumResultCols routine to obtain a count of the number of resultant columns. The application sets values in the CLI descriptor area for the description of the corresponding target specifications either explicitly using the routines SetDescField and SetDescRec or implicitly using the routine BindCol.

When an SQL-statement is prepared or executed immediately, a description of the dynamic parameters is automatically provided in the applicable CLI descriptor area if this facility is supported by the current SQL-connection. An attribute associated with the allocated SQL-connection indicates whether this facility is supported. The value of the attribute may be retrieved using the routine GetConnectAttr. The application sets values in the CLI descriptor area for the description of dynamic parameter values and, regardless of whether automatic population is supported, in the CLI descriptor area for the description of dynamic parameters either explicitly using the routines SetDescField and SetDescRec or implicitly using the routine BindParam.

When a dynamic select statement is executed, a cursor is implicitly declared and opened. The cursor name can be supplied by the application by using the routine SetCursorName. If a cursor name is not supplied by the application, an implementation-dependent cursor name is generated. The same cursor name is used for each implicit cursor within a single allocated SQL-statement. The cursor name can be retrieved by using the GetCursorName routine.

The Fetch routine is used to position an open cursor on the next row and retrieve the values of bound columns for that row. A bound column is one whose target specification in the specified CLI descriptor area defines a location for the target value. Values for unbound columns can be individually retrieved by using the GetCol routine. The GetCol routine also enables the values of character string columns to be retrieved piece by piece. The current row of a cursor can be deleted or updated by executing a preparable dynamic delete statement or a preparable dynamic update statement, respectively, for that cursor under a different allocated SQL-statement to the one under which the cursor was opened. The CloseCursor routine enables a cursor to be closed.

The GetDiagField and GetDiagRec routines obtain diagnostic information about the most recent routine operating on a particular resource. The Error routine is used to obtain diagnostic information about the execution of the most recent routine. The Error routine may be used instead of the resource specific diagnostic routines GetDiagField and GetDiagRec. Information on the number of rows affected by the last executed SQL-statement can be obtained by using the RowCount or GetDiagField routine. The GetFunctions, GetInfo, and GetTypeInfo routines are used to obtain other information about the implementation.

An SQL-transaction is terminated by using the EndTran routine. The Cancel routine is used to cancel the execution of a concurrently executing SQL/CLI routine or to terminate the processing of deferred parameter values and the execution of the associated SQL-statement.

The CLI ExecDirect routine and the CLI Prepare routine each support an input character string parameter identified as StatementText. If P is the value of StatementText, then P shall satisfy the following restrictions:

1. P shall conform to the Format, Syntax Rules, and Access Rules for a {preparable statement} as specified in Subclause 17.6, "{prepare statement}", of the SQL'92 standard.

2. P shall not be a {commit statement} or a {rollback statement}.

3. P shall abide by the Leveling Rules of the level of SQL support claimed by the SQL/ERI Server.

6.5 RDA/SQL-Server interface

An SQL/ERI Server may provide an RDA/SQL-Server protocol interface according to the protocols defined in the RDA'93 standard [9]. The RDA protocols allow communication and interoperability among conforming RDA processors in an OSI communications network. Many vendors are also supporting the RDA protocols in a TCP/IP communications network using agreements specified by the NIST Opens Systems Environment Implementors Workshop (OIW) for RDA accessibility using Internet RFC 1006 for upper layer OSI interface to Internet protocols. This SQL/ERI profile specification allows an SQL/ERI Server to claim conformance to the RDA/SQL-Server interface over an arbitrary communications network. If an application program, acting as an RDA client, is able to form an association with an SQL/ERI Server and communicate thereafter using RDA protocols subject to the implementor agreements specified by the Open Systems Environment Implementor's Workshop (e.g. in [16]), then the SQL/ERI Server may claim conformance to the RDA/SQL-Server interface style.

Reference [9] describes the services of the RDA standard in terms of an RDA Client, an 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).

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 services:

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 initilizes 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 back.

RDA Stored Execution. Support for the basic requirements specified above and, in addition, support for the RDA Stored Execution Functional Unit as specified in the RDA'93 standard and with implementor agreements for the Stored Execution profile as specified in [16].

RDA Status. Support for the basic requirements specified above and, in addition, support for the RDA Status Functional Unit as specified in the RDA'93 standard and with implementor agreements for the Status profile as specified in [16].

RDA Cancel. Support for the basic requirements specified above and, in addition, support for the RDA Cancel Functional Unit as specified in the RDA'93 standard and with implementor agreements for the Cancel profile as specified in [16].

RDA TP Application Context. Support for the basic requirements specified above 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), and with implementor agreements for Distributed Transaction Processing as specified in [16].