SQL Descriptor Area (SQLDA)
An SQL descriptor area is used as a communication area between an application program and CONNX Embedded SQL for dynamic SQL. It is used for communicating information between CONNX Embedded SQL and the application program in both directions.
The information for a dynamic SQL statement that can be retrieved from CONNX Embedded SQL by an application program using an SQLDA originates from either of two sources:
OUTPUT SQLDA
The derived column list of a dynamic SELECT statement.
The application program can retrieve information about the layout of the resulting format of a SELECT statement. The information comprises a list of elements where each element describes the corresponding derived column. An SQLDA describing this type of information is called an output SQLDA. The information is assigned to the output SQLDA by either an extended PREPARE statement (example 1a) or a separate DESCRIBE statement (example 1b). The keyword OUTPUT is the default and therefore optional.
Example 1a:
EXEC SQL
PREPARE statement_id INTO :output_sqlda FROM dyn_sql_statement;
Example 1b:
EXEC SQL
PREPARE statement_id FROM :dyn_sql_statement;
EXEC SQL
DESCRIBE statement_id INTO OUTPUT :output_sqlda;
INPUT SQLDA
The host variable markers in a dynamic SQL statement.
The application program can retrieve information about all host variable markers used in a dynamic SQL statement. The information comprises a list of elements where each element describes the corresponding host variable marker. An SQLDA describing this type of information is called an input SQLDA. The information is assigned to the input SQLDA by either an extended PREPARE statement (example 2a) or a separate DESCRIBE statement (example 2b). The keyword INPUT is mandatory.
Example 2a:
EXEC SQL
PREPARE statement_id INTO INPUT :input_sqlda FROM dyn_sql_statement;
Example 2b:
EXEC SQL
PREPARE statement_id FROM :dyn_sql_statement;
EXEC SQL
DESCRIBE statement_id INTO INPUT :input_sqlda;
Both input and output SQLDAs can be specified in the same PREPARE and DESCRIBE statements. However, one SQLDA cannot be used for both an input and an output SQLDA simultaneously.
Once CONNX Embedded SQL has filled an SQLDA with this information, the application program must provide a host variable reference for each element. This must be done prior to the execution of the prepared statement.
Corresponding to the two types of SQLDAs, two types of host variable references must be supplied.
Target host variables for receiving resultant data
The elements of an output SQLDA associated with a prepared SELECT statement each describe the expected format of the data to be received. The application program must assign a suitable host variable which is capable of receiving the expected data to each element. CONNX Embedded SQL can now determine where to copy the resulting data by means of the pointer reference in each element. Such output SQLDA is only used in conjunction with a FETCH statement. Example:
EXEC SQL
FETCH ABC USING DESCRIPTOR :output_sqlda;
Host variables as host variable marker replacements
The elements of an input SQLDA each describe the expected format of any additional parameters required by the prepared statement as represented by host variable markers. The application program must assign a suitable host variable to each element of the input SQLDA, and each host variable must be loaded with the desired value before the execution of the prepared statement. Such input SQLDA is used in conjunction with either an OPEN statement (example A) or an EXECUTE statement (example B).
Example A:
EXEC SQL
OPEN ABC USING DESCRIPTOR :input_sqlda;
Example B:
EXEC SQL
EXECUTE statement_id USING DESCRIPTOR :input_sqlda;
The SQLDA Structure
You use the same structure for input and output SQLDA. It consists of two distinct parts:
A header that contains general information about the prepared statement.
A consecutive list of elements that corresponds to fields in the derived column list or the host variable markers.
The structure consists of the four fields of the SQLDA header, immediately followed by as many occurrences of the sqlvar structure as stated in the sqln field.

Field | Description
sqldaid | An eight-byte character string containing the constant SQLDA which serves as an eye catcher for easier memory dump interpretation.
sqldabc | A four-byte integer field of type SAG_INTEGER containing the total length of the SQLDA in bytes, that is, the length of the header plus the length of the variable descriptor elements multiplied by the number of available elements (sqln).
sqln | A two-byte integer field containing the total number of variable descriptor elements allocated in the SQLDA.
sqld | A two-byte integer field containing the total number of variable descriptor elements returned during the execution of a DESCRIBE statement.
sqlvar | An array containing sqln variable descriptor elements.
sqltype | A four-byte integer field of type SAGTYPE containing the data type of the required/specified host variable and whether or not there is an INDICATOR variable present.
sqllen | A four-byte integer field of type SAG_INTEGER containing the length of the required/specified host variable. The interpretation of this field depends on the data type.
reserved | A four-byte integer field of type SAG_INTEGER required for internal purposes.
internal | A two-byte integer field required for internal purposes.
sqlindlen | A two-byte integer field containing the length of the host variable acting as an indicator value, if one is required.
sqlindtype | A four-byte integer field containing the data type of the host variable acting as an indicator value, if one is required.
sqlind | A structure of type SAGPointer containing the pointer to the host variable acting as an indicator value, if one is required.
sqldata | A structure of type SAGPointer containing the pointer to the host variable which is to receive or which contains the data.
sqlname | A structure of type SAGCOLUMN containing the derived column name of the resulting column, the length of the column name and the column type.

The sqlname field is only relevant for an output SQLDA, and only in the particular case when the corresponding derived column has a derived column label.
The sqltype field is set by CONNX Embedded SQL to reflect the particular type of the required field.
The sqltype field also specifies whether or not a indicator variable is required or is supplied. This is shown by the type value being negated.
The sqllen field is also set by CONNX Embedded SQL depending on the value assigned to the sqltype field. This field specifies the required size of the host variable.
Declaring an SQLDA
The SQLDA is a special type of host variable structure. To ensure that the structure has the correct format, the application program should use the definition of the SQLDA provided by CONNX Embedded SQL. To facilitate this, an SQL statement like the following one should be embedded in the application.
EXEC SQL
INCLUDE SQLDA AS sqlda_ptr;
This statement has the effect of generating a declaration of a variable sqlda_ptr at the point where it is specified. This variable can then be used as a pointer to a descriptor area.
Allocating an SQLDA
When using an SQLDA to retrieve descriptive information from CONNX Embedded SQL for input or output purposes, the application program normally does not know the required number of variable descriptions. The application program, however, has to allocate an SQLDA of a certain dimension before the PREPARE or DESCRIBE statements can be issued. In general, there are two techniques which can be used:
The application program allocates an SQLDA of maximum size required for the maximum possible number of derived column list elements or host variable markers. This might cause a significant waste of storage if the maximum has to be set very high.
The application program allocates an SQLDA of minimum size. The dimension of the SQLDA is determined by the sqln element in the SQLDA header. If the number of derived column list elements or host variable markers exceeds this number, CONNX Embedded SQL will refrain from attempting to provide information on the remaining elements or markers. CONNX Embedded SQL, however, does return the correct number of elements in the sqld element of the SQLDA. The application program can then use this number to allocate a new SQLDA of sufficient size and re-issue the PREPARE or DESCRIBE statement. The application program must explicitly have an SQLDA declaration such that the resulting structure is in scope for all SQL statements which access it. Such a declaration does not need to be in a BEGIN DECLARE SECTION.
Determining the Type of SQL statement
Although the SQLDA does not explicitly return the SQL statement type, enough information is returned in the SQLDA for the application program to determine whether or not the dynamic statement is a SELECT statement. If the field sqln is 0, the statement did not contain a derived column list and must therefore be a NON-SELECT statement.