Specifies an alias, cursor, database, table, statement, or
 transaction to VAX SQL.

Additional information available:

ALIASCURSORMODULEDATABASESCHEMASTATEMENT
TABLETRANSACTION

 Specifies the name and the source of the database definitions to be
 used for module compilation and makes the named alias part of the
 implicit environment of an application.  You can name either a file
 or a data dictionary path name to be used for the database
 definitions.

 DECLARE -+------>----------++-----------+-> ALIAS -> FOR -+
          +> scope-options -++> alias ---+                 |
 +---------------------------------------------------------+
 +-+-------->--------+-+-----> PATHNAME ---> path-name -+--+
   +> COMPILETIME ---+ +-----> FILENAME ---> file-spec -+  |
 +-------------------- <-----------------------------------+
 +--+--------------------> -----------------+--------------+
    +--> RUNTIME runtime-options -----------+              |
 +---------------------------- <---------------------------+
 +--+------------------------> --------------+-------------+
    +> DBKEY SCOPE IS --+----> ATTACH ------++             |
                        +----> TRANSACTION -+              |
 +---------------------------------------------------------+
 +-+--------------------+----+---------------------------+-+
   +> database-options -+    +> MULTISCHEMA IS -+> ON  -++ |
                                                +> OFF -+  |
 +---------------------------- <---------------------------+
 +-+-------------------------> --------------------------+-+
   +> DEFAULT CHARACTER SET support-char-set ------------+ |
 +---------------------------- <---------------------------+
 +-+-------------------------> --------------------------+-->;
   +> NATIONAL CHARACTER SET support-char-set -----------+

Additional information available:

COMPILETIMEFILENAMEPATHNAMERUNTIMEDBKEY_SCOPE_IS
MULTISCHEMA_IS_ONMULTISCHEMA_IS_OFFDEFAULT_CHARACTER_SET
NATIONAL_CHARACTER_SET

More Informationscope-optionsaliasDatabase options

 The DECLARE SCHEMA statement used in earlier versions of SQL is
 deprecated syntax:  use DECLARE ALIAS to specify a compile-time SQL
 environment and ATTACH to specify a run-time SQL environment.
 (DECLARE ALIAS retains both the COMPILETIME and the RUNTIME keyword
 from DECLARE SCHEMA to make it easier for you to update syntax in
 existing applications.)

 When SQL executes the first procedure in a module, it attaches to all
 databases with unique aliases declared in that application, across
 all modules.

 The DECLARE ALIAS statements embedded in programs or in the DECLARE
 section of an SQL module must come before any DECLARE TRANSACTION or
 executable SQL statements.  DECLARE ALIAS statements tell the
 application what databases it can compile against.

 scope-options =

 -+-> LOCAL --------------+-->
  +-> GLOBAL -------------+
  +-> EXTERNAL -----------+

Additional information available:

LOCALGLOBALEXTERNAL

 Specifies the scope of the database declaration in programs or module
 language procedures.

 LOCAL scope means that the alias is scoped only to the module.  SQL
 only attaches to a database with LOCAL scope when you execute a
 procedure in the same module without a User Session.

 Specifies the scope of the database declaration in programs or module
 language procedures.

 GLOBAL scope means that the alias is global to procedures in all the
 modules in the application.  GLOBAL scope is the default.

 Specifies the scope of the database declaration in programs or module
 language procedures.

 EXTERNAL scope means that the alias is global to procedures in all
 the modules in the application.  EXTERNAL and GLOBAL scope are
 synonyms.

 An alias is a name for a particular attachment to a database.  You do
 not have to specify an alias in the DECLARE ALIAS statement.  If you
 do not specify an alias, the default alias is used.  The default
 alias in interactive SQL and in precompiled programs is RDB$DBHANDLE.
 In the SQL module language, the default is the alias specified in the
 module header.

 Because DECLARE ALIAS specifies the compiletime environment, this
 keyword is optional.

 A full or partial VMS file specification that specifies the source of
 the schema definitions.  When you use the FILENAME argument, any
 changes you make to database definitions are entered only to the
 database system file, not to the data dictionary.

 If you specify FILENAME:

  o  During compilation, your application attaches to the database
     with that filename and reads metadata from the database
     definitions.

  o  At runtime, your application attaches to the database with that
     that filename.


 You must specify either a FILENAME or a PATHNAME in your database
 specification.

 A full or relative data dictionary path name that specifies the
 source of the database definitions.  When you use the PATHNAME
 argument, any changes you make to database definitions are entered in
 both the the PATHNAME argument if you have the data dictionary on
 your system and you plan to use any data definition statements.

 If you specify PATHNAME:

  o  During compilation, your application attaches to the data
     dictionary database definition and reads metadata from the
     dictionary definitions.  SQL extracts the filename of the Rdb
     database from the dictionary and saves it for use at runtime.

  o  At runtime, your application attaches to the Rdb database
     filename extracted from the dictionary at compilation.


 You must specify either a FILENAME or a PATHNAME in your database
 specification.

 This keyword is provided for compatibility with the DECLARE SCHEMA
 statement used in previous versions of SQL.  You should use the
 CONNECT statement to specify a runtime environment.

Additional information available:

runtime-options

 runtime-options =

  -+-> FILENAME --+-> file-spec --+-+->
   |              +-> parameter --+ |
   +-> PATHNAME --+-> path-name --+-+
                  +-> parameter --+

 Controls when the database key of an erased record may be used again
 by SQL.

 The default is DBKEY SCOPE IS TRANSACTION, which means that SQL can
 reuse the database key of a deleted table row as soon you commit the
 transaction that deleted the original row and disconnect the session.

 For more information, type HELP DBKEY.

 database-options =

 --+--> ELN ---------------------+-->
   +--> NSDS --------------------+
   +--> RDBVMS ------------------+
   +--> RDB030 ------------------+
   +--> RDB031 ------------------+
   +--> RDB040 ------------------+
   +--> RDB041 ------------------+
   +--> RDB042 ------------------+
   +--> RDB050 ------------------+
   +--> VIDA --------------------+
   +--> NOVIDA ------------------+

 By default, SQL uses only the database options used to compile a
 program as valid options for that program.  If you want to use the
 program with other supported databases, you can override the default
 options by specifying database options in the ATTACH or DECLARE ALIAS
 statement.

 Specifying database options in the ATTACH or DECLARE ALIAS statement
 overrides the default established in the precompiler or module
 processor command lines.

 The precompiler database option can, in turn, be overridden by an
 attach to a database at run time.  On the DECLARE statement, SQL sets
 the database options of the specified database.

 Enables multischema naming for the duration of the database
 attachment.

 Disables multischema naming for the duration of the database
 attachment.  Multischema naming is disabled by default.

 Specifies the default character set of the alias at compile time.

 Specifies the national character set of the alias at compile time.

 Specifies a cursor that identifies a result table or a list.

 DECLARE cursor-name --------------------+
 +---------------------------------------+
 +-+----------------+--> TABLE CURSOR ---+
 | +-> INSERT ONLY -+                    |
 | +-> READ ONLY ---+                    |
 | +-> UPDATE ONLY -+                    |
 | +-------------------------------------+
 | +-> FOR -> select-expr ----------------+
 | +--------------------------------------+
 | ++-----------------------------------+-----------------+--->;
 |  +> FOR UPDATE OF -+-> column-name -++                 |
 |                    +------ , <------+                  |
 |                                                        |
 ++---------------++---------+-> LIST CURSOR FOR SELECT-+ |
  +> READ ONLY ---++> SCROLL +                          | |
  +> INSERT ONLY -+                                     | |
 +------------------------------------------------------+ |
 +> column-name WHERE CURRENT OF table-cursor-name -------+

Additional information available:

INSERT_ONLYREAD_ONLYUPDATE_ONLYFOR_UPDATE_OF
SCROLLLIST_CURSORWHERE_CURRENT_OF

More Informationselect expr

 Position insert-only cursors on a row that has just been inserted so
 that you can load data values into lists or rows of that row.

 Read-only cursors can be used to access row information from a result
 table whenever you do not intend to update the database.  For
 example, you could use a read-only cursor to fetch row and column
 information for display.

 Use an update cursor when you plan to update most of the records you
 are fetching.  (The update cursor causes Rdb/VMS to apply more
 restrictive locking during the initial read operation, so that locks
 don't need to be upgraded later from READ to exclusive WRITE.) This
 may help to avoid deadlocks.

 Use update table cursors (the default) to modify table rows.

 The DECLARE CURSOR statement defines a cursor, a result table that
 exists through execution of more than one SQL statement.  Host
 language programs require cursors to individually process rows in a
 result table.

 The result table is created by an OPEN statement.  FETCH and CLOSE
 statements can operate on a cursor after it is opened.

 You can create cursors using three classes of the DECLARE CURSOR
 statement:

  o  The static DECLARE CURSOR statement is executed immediately.

  o  The Dynamic DECLARE CURSOR statement is also executed
     immediately.  You can precompile the dynamic DECLARE STATEMENT or
     use it as part of the declare statement section in an SQL module.
     The cursor name is known at compile time and the select statement
     is determined at run time.  You must supply a parameter for the
     cursor name.

  o  The Extended Dynamic DECLARE CURSOR statement must be precompiled
     or used as part of a procedure in the SQL module.  You must
     supply parameters for the cursor name and for the identifier of a
     prepared SELECT statement that is prepared at run time.


 SQL provides two types of cursor:  table cursors (the default) and
 list cursors.

  o  Use table cursors to access individual rows of a result tables.

  o  Use list cursors to access individual elements in a list.  For
     details about lists, see the section on LIST_CURSOR.

 Specifies the columns in a cursor that you or your program might
 later modify with an UPDATE statement.  The column names in the FOR
 UPDATE clause must belong to a table or view named in the FROM
 clause.

 You do not have to specify the FOR UPDATE clause of the DECLARE
 CURSOR statement to later modify rows using the UPDATE statement.
 However, if you do specify FOR UPDATE and later specify columns in an
 UPDATE statement that are not in the FOR UPDATE clause, VAX SQL
 issues a warning message and proceeds with the update modifications.
 If you do not specify a FOR UPDATE clause, you can update any column
 using the UPDATE statement.  VAX SQL will not issue any messages.

 SQL considers as read-only cursors those that:

  o  Use the DISTINCT argument to eliminate duplicate rows from the
     result table

  o  Name more than one table or view in the FROM clause

  o  Include a function in the select list

  o  Contain a GROUP BY or HAVING clause

  o  Contain an ORDER BY clause


 With the exception of cursors containing an ORDER BY clause, you
 cannot refer to read-only cursors in UPDATE or DELETE statements.

 Specifies that Rdb/VMS will be able to read the items in a list from
 either direction or at random.  The SCROLL keyword must be used if
 the following fetch options are desired:

  o  NEXT

  o  PRIOR

  o  FIRST

  o  LAST

  o  RELATIVE

  o  ABSOLUTE


 If SCROLL is not specified, the default for FETCH is NEXT.

 Specifies a cursor used to access lists, as opposed to a table
 cursor.

 A list is an ordered collection of elements of the data type LIST OF
 BYTE VARYING.  A list is equivalent to an RDO segmented string.  You
 can use lists to scan through very large data structures from within
 a language that does not support objects of such size.

 Lists exist as a set of elements within a row of a table.  Each list
 cursor must reference a table cursor, which provides the row context.

Additional information available:

Examples

 Example 1:  Creating a table that contains a list.

 SQL> CREATE TABLE RESUMES
 (FIRST_NAME CHAR(10),
 cont> LAST_NAME CHAR(14),
 cont> RESUME LIST OF BYTE VARYING);

 Example 2:  Showing a table that contains a list.

 SQL> SHOW TABLE RESUMES;
 Information for table RESUMES

 Columns for table RESUMES:
 Column Name                     Data Type        Domain
 -----------                     ---------        ------
 FIRST_NAME                      CHAR(10)
 LAST_NAME                       CHAR(14)
 RESUME                          VARBYTE LIST
                                          Segment Length: 512

 Table constraints for RESUMES:
 No constraints found

 Constraints referencing table RESUMES:
 No constraints found

 Storage Map for table RESUMES:
 No Storage Map found

 Triggers on table RESUMES:
 No triggers found

 Example 3:  Inserting data into a list.

 SQL> DECLARE TBLCURSOR INSERT ONLY TABLE CURSOR FOR SELECT EMPLOYEE_ID,
 cont> RESUME FROM RESUMES;
 SQL> DECLARE LSTCURSOR INSERT ONLY LIST CURSOR FOR SELECT RESUME
 cont> WHERE CURRENT OF TBLCURSOR;
 SQL> OPEN TBLCURSOR;
 SQL> INSERT INTO CURSOR TBLCURSOR (EMPLOYEE_ID) VALUES ("00167");
 1 row inserted
 SQL> OPEN LSTCURSOR;
 SQL> INSERT INTO CURSOR LSTCURSOR
 cont> VALUES ("This is the resume for 00167");
 SQL> INSERT INTO CURSOR LSTCURSOR
 cont> VALUES ("Boston, MA");
 SQL> INSERT INTO CURSOR LSTCURSOR
 cont> VALUES ("Digital Equipment Corporation");
 SQL> CLOSE LSTCURSOR;
 SQL> CLOSE TBLCURSOR;
 SQL> COMMIT;

 Example 4:  Displaying data from a list.

 SQL> DECLARE TBLCURSOR2 CURSOR FOR
 cont> SELECT EMPLOYEE_ID, RESUME FROM RESUMES;
 SQL> DECLARE LSTCURSOR2 LIST CURSOR FOR SELECT RESUME
 cont> WHERE CURRENT OF TBLCURSOR2;
 SQL> OPEN TBLCURSOR2;
 SQL> FETCH TBLCURSOR2;
   00167
 SQL> OPEN LSTCURSOR2;
 SQL> FETCH LSTCURSOR2;
  RESUME
  This is the resume for 00167
 SQL> FETCH LSTCURSOR2;
  RESUME
  Boston, MA
 SQL> FETCH LSTCURSOR2;
  RESUME
  Digital Equipment Corporation
 SQL> FETCH LSTCURSOR2;
  RESUME
 %RDB-E-STREAM_EOF, attempt to fetch past end of record stream
 SQL> CLOSE LSTCURSOR2;
 SQL> CLOSE TBLCURSOR2;

 Example 5:  Displaying the segmented string (list) identifier

 SQL> SELECT * FROM RESUMES;
   EMPLOYEE_ID    RESUME
  00167                     1:701:2
 1 row selected

 Specifies the table cursor that provides the row context for the list
 cursor.

 The table cursor must be defined using a DECLARE CURSOR statement.

 select-expr =

 -+-+-> select-clause -----+-+-+--------------------+-+
  | +->( select-expr ) ----+ | +-> order-by-clause -+ |
  | +---------<--------------+                        |
  | +->UNION -+-------+----+                          |
  |           +->ALL -+    |                          |
  +-------<----------------+                          |
  +---------------------------------------------------+
  +-+--------------------+-+----------------------------------+->
    +-> limit-to-clause -+ +-> OPTIMIZE FOR -+-> FAST FIRST -++
                                             +-> TOTAL TIME -+

Additional information available:

OPTIMIZE_FOR

select clauseorder by clauselimit to clause

 select-clause =

 SELECT -+------>------+-> select-list --+
         +-> ALL ------+                 |
         +-> DISTINCT -+                 |
 +------------------------------<--------+
 +-> FROM -++-> table-name -++----->-------------++-+
           |+-> view-name --++> correlation-name +| |
           +---------- , <------------------------+ |
 +--------------------------------------------------+
 ++--------->--------++------------->--------------++
  +> WHERE predicate ++> GROUP BY -+> column-name ++|
                                   +------- , <---+ |
 +--------------------------------<-----------------+
 ++---------->----------+---------------------------->
  +-> HAVING predicate -+

 order-by-clause =

 --> ORDER BY -++-> column-name -+-+---->----+-+-->
               |+-> integer -----+ +-> ASC --+ |
               |                   +-> DESC -+ |
               +------------ , <---------------+

 limit-to-clause =

 ---> LIMIT TO ----> row-limit ---> ROWS -->

 The OPTIMIZE_FOR clause allows applications to specify the preferred
 optimizer strategy.

 If your application runs in batch, accesses all the records in the
 query, and performs updates or writes a report, you should specify
 TOTAL TIME optimization.  Most queries default to TOTAL TIME
 optimization.

 If a query may be canceled prematurely, you should specify FAST FIRST
 optimization.  A good candidate for FAST FIRST optimization would be
 an interactive application that displays groups of records to the
 user, where the user has the option of aborting the query after the
 first few screens.  A query optimized for FAST FIRST returns data to
 the user as quickly as possible, even at the expense of total
 throughput.

 The DECLARE MODULE statement specifies characteristics, such as
 character sets, quoting rules, and the default date format, for a
 module.

 DECLARE MODULE module-name --------+
 +----------------------------------+
 +-+-----------------------------+--+
   +--> DIALECT environment   ---+  |
 +----------------------------------+
 +-+---------------------------+----+
   +--> char-set-options    ---+    |
 +----------------------------------+
 +-+------------------------+-------+
   +--> SCHEMA schema-name -+       |
 +----------------------------------+
 +---+---------------------------+--+
     +--> AUTHORIZATION auth-id -+  |
 +----------------------------------+
 +-+------------------------------+--> ;
   +--> module-language-options --+

Additional information available:

MODULE module nameDIALECT environmentchar set optionsSCHEMA schema name
AUTHORIZATION auth idmodule language options

 The module-name is an optional name for the module.  If you do not
 supply a module name, the default name is SQL_MODULE.

 Use any valid VMS name.  However, the name must be unique among the
 modules that are linked together to form an executable image.

 environment =

 --+--> SQL92 ----+-->
   +--> SQL89 ----+
   +--> SQLV40 ---+
   +--> MIA ------+

Additional information available:

More information

 Controls the following settings:

  o  Whether the length of character string parameters, columns, and
     domains are interpreted as characters or octets.

  o  Whether double quotes are interpreted as string literals or
     delimited identifiers

  o  Whether or not identifiers may be keywords

  o  Which views are read-only

  o  Whether columns with the DATE or CURRENT_TIMESTAMP data type are
     interpreted as VMS or SQL92 format.


 The DIALECT clause lets you specify the settings with one clause,
 instead of specifying each setting individually.  Because the module
 processor processes the module clauses sequentially, the DIALECT
 clause can override the settings of clauses specified before it or be
 overridden by clauses specified after it.

 If you set the dialect to SQL92, the default constraint evaluation
 time setting is changed from DEFERRABLE to NOT DEFERRABLE.

 char-set-options =

 --+---------------->--------------+-----+
   +--> NAMES ARE names-char-set --+     |
 +------------------<--------------------+
 ++-+--------------->-------------------------------+-+->
  | +--> LITERAL CHARACTER SET support-char-set ----+ |
  | +--> NATIONAL CHARACTER SET support-char-set ---+ |
  | +--> DEFAULT CHARACTER SET support-char-set ----+ |
  | +--> IDENTIFIER CHARACTER SET names-char-set ---+ |
  +---------------------------<-----------------------+

Additional information available:

DEFAULT_CHARACTER_SETIDENTIFIER_CHARACTER_SETLITERAL_CHARACTER_SET
NATIONAL_CHARACTER_SET

NAMES ARE names char set

 The DEFAULT CHARACTER SET specifies the character set for parameters
 that are not qualified by a character set.  The default is DEC_MCS.
 This clause overrides the character set specified in the NAMES ARE
 clause.

 The IDENTIFIER CHARACTER SET clause specifies the character set used
 for database object names such as table names and column names.  This
 clause overrides the character set specified in the NAMES ARE clause.
 The specified character set must contain ASCII.

 The LITERAL CHARACTER SET clause specifies the character set for
 literals that are not qualified by a character set or national
 character set.  If you do not specify a character set in this clause
 or in the NAMES ARE clause, the default is DEC_MCS.  This clause
 overrides the character set for unqualified literals specified in the
 NAMES ARE clause.

 The NAMES ARE clause specifies the character set used for the
 default, identifier, and literal character sets for the module.  Also
 specifies the character string parameters that are not qualified by a
 character set or national character set.  If you do not specify a
 character set, the default is DEC_MCS.

 You must ensure that the character set specified in this clause
 matches the character set of all the databases attached to by any
 particular connection and must contain ASCII.

 The NATIONAL CHARACTER SET clause specifies the character set for
 literals qualified by the national character set.

 The SCHEMA clause specifies the default schema name for the module.
 The default schema is the schema to which SQL statements refer if
 those statements do not qualify table and other schema names with an
 authorization identifier.  If you do not specify a default schema
 name for a module, you must specify a default authorization
 identifier.

 The AUTHORIZATION clause specifies the authorization identifier for
 the module.  If you do not specify a schema clause, the authorization
 identifier specifies the default schema.

 module-language-options =

 -+-+---> ALIAS alias-name --------------------------+-+-->
  | +---> CHARACTER LENGTH -+-> CHARACTERS -+--------+ |
  | |                       +-> OCTETS -----+        | |
  | +---> QUOTING RULES environment -----------------+ |
  | +---> KEYWORD RULES environment -----------------+ |
  | +---> VIEW UPDATE RULES environment -------------+ |
  | +---> DEFAULT DATE FORMAT --+--> SQL92 -+--------+ |
  | |                           +--> VMS ---+        | |
  | +---> PARAMETER  COLONS -------------------------+ |
  | +---> RIGHTS --+--> INVOKER ---+-----------------+ |
  |                +--> RESTRICT --+                   |
  +------------------------<---------------------------+

Additional information available:

ALIASCHARACTER_LENGTHDEFAULT_DATE_FORMATKEYWORD_RULES
PARAMETER_COLONSQUOTING_RULESRIGHTSVIEW_UPDATE_RULES

 The ALIAS clause pecifies the module alias.  If you do not specify a
 module alias, the default alias is the authorization identifier for
 the module.

 The CHARACTER_LENGTH clause specifies whether the length of character
 string parameters, columns, and domai are interpreted as characters
 or octets.  The default is octets.

 The DEFAULT DATA FORMAT clause controls the default interpretation
 for columns with the DATE or CURRENT_TIMESTAMP data type.  The DATE
 and CURRENT_TIMESTAMP data types can be either VMS or SQL92 format.

 If you specify VMS, both data types are interpreted as VMS format.  A
 VMS format data type is compatible with Rdb/ELN and versions of
 Rdb/VMS prior to Version 4.1, but cannot be used in date-time
 arithmetic.  The VMS format DATE and CURRENT_TIMESTAMP contain YEAR
 to SECOND fields, like a TIMESTAMP.

 If you specify SQL92, both data types are interpreted as SQL92
 format.  The SQL92 format DATE contains only the YEAR to DAY fields.

 The default is VMS.

 Use the DEFAULT DATE FORMAT clause, rather than the /ANSI_DATE
 qualifier, because the qualifier will be deprecated in a future
 release.

 The KEYWORD RULES clause controls whether or not identifiers may be
 keywords.  If you specify SQL92, SQL89, or MIA, you cannot use
 keywords as identifiers, unless you enclose them in double quotes.
 If you specify SQLV40, you can use keywords as identifiers.  The
 default is SQLV40.

 Use the KEYWORD RULES clause, rather than the /SQLOPTIONS =
 ANSI_IDENTIFIER qualifier because the qualifier will be deprecated in
 a future release.

 If you use the PARAMETER COLONS clause, all parameter names must
 begin with a colon (:).  This is valid in context files for module
 language only.  This rule applies to both declarations and references
 of module language procedure parameters.  If you do not use this
 clause, no parameter name may begin with a colon.

 The current default behavior is no colons are used.  However, this
 default is deprecated syntax.  In the future, required colons will be
 the default, because it allows processing of ANSI standard modules.

 Use the PARAMETER COLONS clause, rather than the /ANSI_PARAMETERS
 qualifier, because the qualifier will be deprecated in a future
 release.

 The QUOTING RULES clause controls whether double quotes are
 interpreted as string literals or delimited identifiers.  If you
 specify SQL92, SQL89, or MIA, SQL interpretes double quotes as
 delimited identifiers.  If you specify SQLV40, SQL interpretes double
 quotes as literals.  The default is SQLV40.

 Use the QUOTING RULES clause, rather than the /SQLOPTIONS =
 ANSI_QUOTING qualifier, because the qualifier will be deprecated in a
 future release.

 The RIGHTS clause specifies whether or not a module must be executed
 by a user whose authorization identifier matches the module
 authorization identifier.

 The VIEW UPDATE RULES clause specifies whether or not the SQL module
 processor applies the ANSI/ISO standard for updatable views to all
 views created during compilation.

 If you specify SQL92, SQL89, or MIA, the SQL module processor applies
 the ANSI/ISO standard for updatable views to all views created during
 compilation.  Views that do not comply with the ANSI standard for
 updatable views cannot be updated.

 The DECLARE DATABASE statement is supported only for upward
 compatibility.  For information on declaring databases see the Help
 topic on ATTACH (for the interactive or runtime environment) or
 DECLARE ALIAS (for the compiletime environment).

 The DECLARE SCHEMA statement is deprecated syntax.  For information
 on declaring databases see the Help topic on ATTACH (for the
 interactive or runtime environment) or DECLARE ALIAS (for the
 compiletime environment).

 DECLARE --+-> statement-name --+-> STATEMENT ;
           +-------  , <--------+

Additional information available:

More Information

 DECLARE STATEMENT is used only in preprocessed programs that include
 dynamic SQL.  DECLARE STATEMENT documents a statement name later used
 in a PREPARE, DECLARE CURSOR, or DESCRIBE statement.  Including the
 DECLARE STATEMENT is optional.

 DECLARE -+-> table-name --+-> TABLE --+
          +-> view-name ---+           |
 +-------------------------------------+
 +-> ( -++-> declare-col-definition -++-> ) --> ;
        |+-> table-constraint -------+|
        +------------ , <-------------+

Additional information available:

More Informationdeclare col definitiontable constraint

 The DECLARE TABLE statement is used in preprocessed programs and as
 part of SQL module procedures.  It is an alternative to SQL's
 implicit declaration of a table based on the table definition in the
 database file or data dictionary.  For a table named in a DECLARE
 TABLE statement, SQL does not check the database or dictionary to
 compare the table definition with the explicit declaration.

 The DECLARE TABLE statement documents a table definition in the
 source code of the program.  It allows program references to tables
 that are created by other modules of a program or that are created
 dynamically.  Using DECLARE TABLE can also improve precompiler or
 module processor performance because SQL does not have to retrieve
 the table definition from the database.  You can also use DECLARE
 TABLE to specify a subset of a table definition when the program
 needs to use only some of the columns in the table.

 For details on specifying column definitions and table constraints,
 see the Help topic on CREATE TABLE.

 declare-col-definition =

 --> column-name --> data-type -++---------->------------++->
                                |+-> col-constraint -----+|
                                |+-> sql-and-dtr-clause -+|
                                +-----------<-------------+

 The definition for a column in the table.  The column definition must
 correspond to a table definition in the schema.

Additional information available:

column namedata typecol constraintsql and dtr clause

 The name of the column you are defining.

 data-type =
  -+-> char-data-types ---------------------------+-->
   +-> TINYINT --------------+-----+--------+-----+
   +-> SMALLINT -------------+     +-> (n) -+     |
   +-> INTEGER --------------+                    |
   +-> BIGINT ---------------+                    |
   +-> LIST OF BYTE VARYING -+                    |
   +-> DECIMAL -+-+-----------------------------+-+
   +-> NUMERIC -+ +-> ( --> n -+--------+-> ) --+ |
   |                           +-> , n -+         |
   +-> FLOAT -+--------+--------------------------+
   |          +-> (n) -+                          |
   +-> REAL --------------------------------------+
   +-> DOUBLE PRECISION --------------------------+
   +-> date-time-data-types ----------------------+

 The data type of the column you are defining.

Additional information available:

char data types

 char-data-types =

 -+-> CHAR  +--------+-+-------------------------------------+-+->
  |         +-> (n) -+ +-> CHARACTER SET character-set-name -+ |
  +-> NCHAR ---------+-+--------+------------------------------+
  +-> NATIONAL CHAR -+ +-> (n) -+                              |
  +-> VARCHAR (n) -----+-------------------------------------+-+
  |                    +-> CHARACTER SET character-set-name -+ |
  +-> NCHAR VARYING ----------+------+---------+---------------+
  +-> NATIONAL CHAR VARYING --+      +-> (n) --+               |
  +-> LONG VARCHAR  -------------------------------------------+

 A valid character data type and character set name.

 col-constraint=
  ---+----------------->------------+---+
     +->CONSTRAINT constraint-name -+   |
   +------------------------------------+
   +-> PRIMARY KEY -----------------+
   +-> UNIQUE ----------------------+
   +-> NOT NULL --------------------+
   +-> CHECK (predicate) -----------+
   +-> references-clause -----------+
   +------------>-------------------+
   +-------------<------------------+
   +----+----------------------------+-->
        +--> constraint-attributes --+

Additional information available:

More Informationreferences clause

 A col-constraint is a constraint definition that applies to the
 specified column.  The five types of column constraints are PRIMARY
 KEY, NOT NULL, UNIQUE, CHECK, and FOREIGN KEY constraints.  FOREIGN
 KEY constraints are created with the REFERENCES clause.  A constraint
 has the attributes of DEFERRABLE or NOT DEFERRABLE.  See the
 description under constraint_attributes for more detail regarding
 DEFERRABLE and NOT DEFERRABLE.

 The PRIMARY KEY column constraint declares a column to be a primary
 key.  A primary key constraint defines one or more columns that make
 a row in a table different from all others.  SQL requires that values
 in a primary key column be unique and not null.  Therefore, you need
 not specify the UNIQUE and NOT NULL column constraints for a primary
 key column.

 The NOT NULL column constraint restricts values in the column to
 non-null values.

 The UNIQUE column constraint specifies that values in the associated
 column must be unique.  You can use either UNIQUE or PRIMARY KEY
 keywords to define one or more columns as a unique key for a table.

 The CHECK column constraint specifies a predicate that column values
 inserted into the table must satisfy.  Predicates in CHECK column
 constraints can refer directly only to the column with which they are
 associated.

 The optional CONSTRAINT constraint-name specifies a name for a column
 constraint that is used in several ways:

  o  The INTEG_FAIL error message specifies the name when an INSERT,
     UDPATE, or DELETE statement violates the constraint

  o  ALTER TABLE DROP CONSTRAINT statements specify the name to delete
     a table constraint

  o  SHOW TABLE statements display the names of column and table
     constraints

  o  EVALUATING clause of the SET TRANSACTION and DECLARE TRANSACTION
     statements specifies constraint names


 The CONSTRAINT clause is optional.  If you omit the constraint name,
 SQL creates a name.  However, Digital recommends that you always name
 column and table constraints.  The constraint names generated by SQL
 may be obscure and, in programs, may change between compile time and
 run time.  If you supply a constraint name with the CONSTRAINT
 clause, it must be unique in the database, or in the schema if you
 are using a multischema database.

 references-clause =

 REFERENCES referenced-table-name ---+
  +-----------------<----------------+
  +-+--------------------->-------------------+->
    +-> ( -+-> referenced-column-name -+-> ) -+
           +----------- , <------------+

 Specifies the name (or names) of a column (or columns) that is a
 primary key or key in the referenced table.  When the REFERENCES
 clause is selected as a column constraint, the column specified in
 the column-definition clause becomes a foreign key for the
 referencing table (the table being defined).  When the REFERENCES
 clause is selected as a table constraint, the column name or column
 names specified in the FOREIGN KEY clause become a foreign key for
 the referencing table.

 The referenced_table_name specifies the name of the table that
 contains the unique key or primary key referenced by the referencing
 table.  To declare a constraint that refers to a unique or primary
 key in another table, you must have the SQL access right REFERENCES
 or CREATETAB to the referenced table.  A computed column cannot have
 a REFERENCES clause.

 For a column constraint, the referenced_column_name is the name of
 the column that is a unique key or primary key in the referenced
 table.  For a table constraint, the the referenced_column_name is the
 name of the column or columns that are a unique key or primary key in
 the referenced table.  The unique key can be defined with either the
 UNIQUE or PRIMARY KEY keywords.  If you omit the
 referenced_column_name, the primary key is selected by default.

 sql-and-dtr-clause =

 -+-> QUERY HEADER IS -+> quoted-string --+-----------------+->
  |                    +------ / <--------+                 |
  +-> EDIT STRING IS quoted-string -------------------------+
  |                                                         |
  +-> QUERY NAME FOR -+-> DTR --------+-> IS quoted-string -+
  |                   +-> DATATRIEVE -+                     |
  +-> DEFAULT VALUE FOR -+-> DTR --------+-> IS literal ----+
                         +-> DATATRIEVE -+





 Optional formatting clauses allow you to modify data displays or
 query characteristics for interactive SQL users and DATATRIEVE users.

 A query header specifies a string that interactive SQL or DATATRIEVE
 displays in place of the column name when it retrieves values from a
 column.  An edit string specifies a string that controls how
 interactive SQL or DATATRIEVE formats the display of values in a
 column.

 DEFAULT VALUE and QUERY NAME are active only from DATATRIEVE.

 table-constraint =
 ---+---------------->------------------+----+
    +-> CONSTRAINT constraint-name -----+    |
  +------------------------------------------+
  +-> PRIMARY KEY -> ( -+-> column-name -+-> ) ------+
  |                     +------- , <-----+           |
  +-> UNIQUE -> ( -+-> column-name -+-> ) -----------+
  |                +------- , <-----+                |
  +-> CHECK (predicate) -----------------------------+
  +-> FOREIGN KEY -> ( -+-> column-name -+-> ) --+   |
                        +------- , <-----+       |   |
    +-----------------------<--------------------+   |
    +-> references-clause ------------->-------------+
    +------------------------------------------------+
    +-----+---------------------------+------------->
          +-> constraint-attributes --+

Additional information available:

More Informationreferences clause

 A table-constraint is a constraint definition that applies to the
 whole table.  The four types of table constraints are PRIMARY KEY,
 UNIQUE, CHECK, and FOREIGN KEY constraints.  You can also optionally
 specify a constraint name.

 The PRIMARY KEY constraint is used to declare a column or columns as
 a primary key for the table being defined.  Any foreign key that
 refers to this column must refer to this primary key.

 The UNIQUE table constraint specifies that the combination of values
 for the columns named must be unique in a row.  Columns named in the
 list must be defined with the NOT NULL column constraint.  A unique
 key can be defined with either the UNIQUE or PRIMARY KEY keywords.

 The CHECK table constraint specifies a predicate that column values
 inserted into the table must satisfy.  Predicates in CHECK table
 constraints can refer to any column in the table.  Column select
 expressions within the predicate can refer to other tables in the
 schema.

 The FOREIGN KEY table constraint specifies the column or columns that
 you want to declare as a foreign key in the table you are defining.

 The optional CONSTRAINT constraint-name clause specifies a name for a
 column or table constraint.  The name specified is used in several
 ways:

  o  The INTEG_FAIL error message specifies the name when an INSERT,
     UDPATE, or DELETE statement violates the constraint

  o  ALTER TABLE DROP CONSTRAINT statements specify the name to drop a
     table constraint

  o  SHOW TABLE statements display the names of column and table
     constraints

  o  EVALUATING clause of the SET TRANSACTION and DECLARE TRANSACTION
     statements specifies constraint names.

 references-clause =

 REFERENCES referenced-table-name ---+
  +-----------------<----------------+
  +-+--------------------->-------------------+->
    +-> ( -+-> referenced-column-name -+-> ) -+
           +----------- , <------------+

 Specifies the name of a column or columns that are a primary key or
 unique key in the referenced table.  When the REFERENCES clause is
 selected as a column-constraint, the column specified in the
 col-definition clause becomes a foreign key for the referencing table
 (the table being defined).  When the REFERENCES clause is selected as
 a table constraint, the column name or column names specified in the
 FOREIGN KEY clause become a foreign key for the referencing table.

 The referenced_table_name is the name of the table that contains the
 unique key or primary key referenced by the referencing table.  You
 must have the SQL access right REFERENCES or CREATETAB to the
 referenced table.

 For a column constraint, the referenced_column_name is the name of
 the column that is a unique key or primary key in the referenced
 table.  For a table constraint, the referenced_column_name is the
 name of the column or columns that are a unique key or primary key in
 the referenced table.  If you do not supply a referenced_column_name,
 the primary key in the referenced table is used by default.

 DECLARE TRANSACTION --+------------------+----> ;
                       +-> tx-options ----+
                       +-> db-txns -------+

Additional information available:

More Informationtx optionsdb txns

 Specifies the characteristics for a default transaction.  A
 transaction is a group of statements whose changes can be made
 permanent or undone as a unit.  By default, SQL starts transactions
 with the characteristics READ WRITE, WAIT, and ISOLATION LEVEL
 SERIALIZABLE, reserving tables as required for statements that refer
 to the tables.

 In contrast to the SET TRANSACTION statement, the DECLARE TRANSACTION
 statement is not executable and therefore does not start a
 transaction.  The declarations in a DECLARE TRANSACTION statement
 take effect when SQL starts an implicit transaction, that is, with
 the first executable data manipulation or data definition statement
 following the DECLARE TRANSACTION, COMMIT, or ROLLBACK statement.

 The characteristics specified in a DECLARE TRANSACTION statement
 affect all transactions (except those started by the SET TRANSACTION
 statement) until you issue another DECLARE TRANSACTION statement.
 The characteristics specified in a SET TRANSACTION statement affect
 only that transaction.

 If you end the transaction with a COMMIT statement, all changes made
 to the database by statements in the transaction are made permanent.
 If you end the transaction with a ROLLBACK statement, none of the
 changes made to the database by the statements takes effect.  If you
 then start another transaction with a data manipulation or data
 definition statement, that transaction also has the characteristics
 originally specified in the DECLARE TRANSACTION statement.

 In interactive SQL, you can change transaction characteristics with
 another DECLARE or SET TRANSACTION statement, but only if a
 transaction is not currently active.  In programs, DECLARE
 TRANSACTION can apply only one set of transaction characteristics to
 a precompiled source file or compiled SQL module.

 tx-options =

  -+---> BATCH UPDATE ----------->---------------------------+->
   +-+------------------+-+------>-----------------------+-+ |
     +-> READ ONLY    --+ +-> WAIT -+--------->--------+-+ | |
     +-> READ WRITE   --+ |         +-> timeout-value -+ | | |
                          +-> NOWAIT --------------------+ | |
     +----------------------<------------------------------+ |
     +-+-------------------->-----------------------+---+    |
       +-> ISOLATION LEVEL ---+-> READ COMMITTED ---+   |    |
                              +-> REPEATABLE READ --+   |    |
                              +-> SERIALIZABLE -----+   |    |
     +--------------------------------------------------+    |
     +-+----------------->-----------------------+-+         |
       +-> EVALUATING -+-> evaluating-clause --+-+ |         |
                       +-------- , <-----------+   |         |
     +---------------------------------------------+         |
     +-+----------------->-----------------------+----->-----+
       +-> RESERVING --+-> reserving-clause ---+-+
                       +---------- , <---------+

Additional information available:

BATCH_UPDATEREAD_ONLYREAD_WRITEWAIT
NOWAITISOLATION_LEVELEVALUATINGRESERVING

 BATCH UPDATE reduces overhead in large load operations by not writing
 to any journal files.  No rollback is possible for batch update
 transactions.

 READ ONLY specifies that you want to use a snapshot of the database
 for only reading records.

 READ WRITE specifies that you want to use a locking mechanism of SQL
 to get consistency in data retrieval and update for reading and
 writing records.

 WAIT or NOWAIT determines what your transaction does when it
 encounters a locked record.  WAIT waits for other transactions to
 complete and then proceeds.

Additional information available:

timeout-value

 An integer that specifies the number of seconds for a given
 transaction to wait for other transactions to complete.  This
 interval is only valid for the transaction specified in the SET
 TRANSACTION statement.  Subsequent transactions return to the
 database default timeout interval.  A timeout value of zero specifies
 NOWAIT.

 WAIT or NOWAIT determines what your transaction does when it
 encounters a locked record.  NOWAIT returns an error message when it
 encounters a locked record.

 Defines the degree to which database operations in an SQL transaction
 are affected by database operations in concurrently executing
 transactions.  It determines the extent to which the database
 protects the consistency of your data.

 Rdb/VMS supports isolation levels READ COMMITTED, REPEATABLE READ,
 and SERIALIZABLE.  When you use SQL with Rdb/VMS databases, SQL by
 default executes a transaction at isolation level SERIALIZABLE.  The
 higher the isolation level the more isolated a transaction is from
 other currently executing transactions.  Isolation levels determine
 the type of phenomena that are allowed to occur during the execution
 of concurrent transactions.  Two phenomena define SQL isolation
 levels for a transaction:

  o  Nonrepeatable read

     Allows the return of different results within a single
     transaction when a SQL operation reads the same row in a table
     twice.  Nonrepeatable reads can occur when another transaction
     modifies and commits a change to the row between transaction
     reads.

  o  Phantom

     Allows the return of different results within a single
     transaction when a SQL operation retrieves a range of data values
     (or similar data existence check) twice.  Phantoms can occur if
     another transaction inserted a new record and committed the
     insertion between executions of the range retrieval.


 Each isolation level differs in the phenomena it allows:

  o  ISOLATION LEVEL SERIALIZABLE transaction

     Does not allow either nonrepeatable reads or phantoms.

  o  ISOLATION LEVEL REPEATABLE READ transaction

     Does not allow nonrepeatable reads but does permit phantoms.

  o  ISOLATION LEVEL READ COMMITTED transaction

     Allows both nonrepeatable reads and phantoms.

 EVALUATING determines the point at which the named constraint(s) are
 evaluated.  If you specify VERB TIME, they are evaluated when the
 data manipulation statement is issued.  If you specify COMMIT TIME,
 they are evaluated when the COMMIT statement executes.  For READ ONLY
 transactions, this clause is allowed but meaningless.

Additional information available:

evaluating-clause

 evaluating-clause =

 -+-----------+-> constraint-name -> AT -+-> VERB TIME --+->
  +-> alias. -+                          +-> COMMIT TIME +
 The point at which the named constraint or constraints are evaluated.
 If you specify VERB TIME, they are evaluated when the data
 manipulation statement is issued.  If you specify COMMIT TIME, they
 are evaluated when the COMMIT statement executes.  For read-only
 transactions, this clause is allowed but is meaningless.

 RESERVING specifies the list of tables to be locked during the
 transaction.

Additional information available:

reserving-clause

 reserving-clause =

 -++-> table-name -++-> FOR +-------- > --++-> READ -+>
  |+-> view-name --+|       +-> EXCLUSIVE ++-> WRITE +
  +------- , <------+       +-> PROTECTED +
                            +-> SHARED ---+
 If constraints were defined for your database, you must include in
 the RESERVING clause any tables that the database system must access
 to evaluate the constraint.

 If you use the RESERVING clause to specify tables, you can access
 only the tables you have reserved.  However, specifying a view in a
 RESERVING clause is the same as specifying the underlying tables on
 which the view is based.

 db-txns =
 -+--------------------------------------------------+>
  ++> ON +> alias +> USING -> ( +-> tx-options +> ) ++
   |     +--- , <-+             +-> DEFAULTS --+    |
   +------------------ AND <------------------------+

Additional information available:

More Information

 Specifies the options for accessing other databases when using the
 declare transaction statement.  These options include the alias for
 the database and whether you want to state the transaction options
 individually or accept the default transaction options of READ WRITE
 WAIT plus the consistency option appropriate for the database system
 you are using.