1  LSE
   DEC Language Sensitive Editor (LSE) is available on the OpenVMS
   platforms only.

   LSE is an advanced text editor that is layered on DECTPU. SQL
   supports two sets of LSE templates, one for interactive SQL and
   one for module language. The templates guide you in entering
   syntactically-correct statements.

                                  NOTE

      The LSE templates provided with Oracle Rdb only support SQL
      syntax through V4.2. The templates do not provide support
      for new and changed syntax after V4.2.

   LSE templates are made up of placeholders representing SQL
   syntax. You can expand a placeholder or token by positioning
   the cursor anywhere on it and pressing CTRL/E. When you expand
   the placeholders, LSE provides the required syntax or indicates
   optional elements.

   For more information about LSE, see the DEC Language Sensitive
   Editor documentation.

   For more information about other editors SQL supports, see the
   online help topic EDIT.
 

2  Invoking_LSE
   You can invoke LSE in either of the following two ways:

   o  To use LSE within interactive SQL, define the logical names
      SQL$EDIT and LSE$ENVIRONMENT:

      $ DEFINE SQL$EDIT LSE
      $ DEFINE LSE$ENVIRONMENT -
      _$ SYS$COMMON:[SYSLIB]LSE$SYSTEM_ENVIRONMENT.ENV

      Then, when you enter the EDIT statement from within SQL, you
      automatically invoke LSE with SQL templates.

   o  To invoke LSE from DCL level, type LSE followed by the name
      of the file you want to edit. The file type determines
      the templates that LSE uses. To invoke the templates for
      interactive SQL, use the file type of SQL; to invoke the
      templates for SQL module language, use the file type of
      SQLMOD. For example, you can type the following commands:

      $ LSE SAMPLE.SQL

      or

      $ LSE SAMPLE.SQLMOD
 

2  General_SQL_Terms
   You can access online help for any placeholder in the LSE
   templates for SQL. To obtain this help while you are editing,
   position your cursor on the placeholder, then press the PF1 and
   PF2 keys in succession.

   The templates include some placeholders for low-level syntax.
   While these topics are essential to SQL, they are so general as
   to not be applicable at top-level help. This topic, General_SQL_
   Terms, serves as a location for the low-level help topics that
   LSE requires.
 

3  check_col_constraint

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

   Specifies a predicate that column values inserted into the table
   must satisfy.
 

3  col_clause
   A placeholder used in LSE templates for the DECLARE TABLE syntax.
   The col-clause placeholder allows the optional expansions of
   either the col-constraint or sql-and-dtr-clause placeholders.

   In the following syntax diagram for col-definition, col-clause
   is represented by the right-most syntax loop that includes col-
   constraint and the sql-and-dtr-clause.

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

   See also the Help topic on col-definition, located at this same
   level.
 

3  column_qualifier
   A placeholder used in LSE templates as an expansion of the
   column-name placeholder. The templates use the term column-
   qualifier to describe leftmost loop in the following syntax
   diagram for the column-name syntax.

 column-name =
 
 ---+----------->-----------------+-> <name-of-column> -->
    +-> <table-name> -------+> . -+
    +-> <view-name> --------+
    +-> <correlation-name> -+
 

   If you expand column-qualifier in the templates, you will see the
   optional items of table-name, view-name, and alias.
 

3  column_name

 column-name =
 
 ---+----------->-----------------+-> <name-of-column> -->
    +-> <table-name> -------+> . -+
    +-> <view-name> --------+
    +-> <correlation-name> -+
 

   You can name columns in CREATE TABLE and ALTER TABLE statements.
   In other SQL statements, the names you give to columns can be
   qualified by table name, view names, or aliases.

   The only time you must qualify column names is when they are
   ambiguous. Joining a table with itself and joining two tables
   with common column names are two cases that require qualified
   column names.

   You always have the option of qualifying column names. In complex
   statements, such qualifiers often make the statements more
   readable.
 

3  col_definition

 
 col-definition =
 
 --> <column-name> --+
     +---------------+
     +---> column-type ---+--------------------------+-+--+
     |                    +->DEFAULT   value-expr    | |  |
     |                    +->column-identity --------+ |  |
     +---> COMPUTED BY value-expr ---------------------+  |
     +-------------------------<--------------------------+
     +-+--------------------+----------------+
       +-> col-constraint --+                |
     +--------------------------<------------+
     ++------------------------+-----+-----------------------+->
      +-> comment-is-clause  --+     +-> sql-and-dtr-clause -+
 
 
 

   The definition for a column in the table. SQL gives you two ways
   to specify column definitions:

   o  By directly specifying a data type to associate with a column
      name

   o  By naming a domain that indirectly specifies a data type to
      associate with a column name

   Either way also allows options of specifying column constraints
   and formatting clauses.
 

3  FILENAME
   FILENAME is a keyword used in SQL syntax that is always followed
   by a required file specification.

   See the online help for file_spec, located at this same level,
   for more information.
 

3  file_spec
   Specifies a valid file specification. A full file specification
   includes:

   o  Network node name

   o  Device directory (on OpenVMS only)

   o  Directory name or list

   o  File name

   o  File type

   o  File version number (on OpenVMS only)

   For example, on OpenVMS a full file specification is:

   SPEEDY::YOURDISK:[YOURDIR]APPLICANTS.RDB;81

   File specifications are used throughout SQL syntax. For
   example, when you first create a database, you give the file
   specifications for the database system files.
 

3  integer
   An integer is a whole number. It may be positive or negative,
   depending on its use, but cannot have a fractional part.

   SQL uses integers in many situations. For example, you specify an
   integer to refer to columns by column number.
 

3  n
   Specifies an integer. For the GRANT statement, the integer
   specifies the earliest relative position of the entry in the
   ACL. For the EDIT statement, the integer tells SQL to save the
   previous n statements.
 

3  parameter
   Parameters are a type of value expression. Many SQL clauses
   that will not accept more general value expressions require
   parameters.

   A parameter is a variable declared in a host language program
   that is associated with an SQL statement. The meaning of
   parameter encompasses host variables named directly in embedded
   SQL statements, actual and formal parameters in programs that
   use SQL module language, and parameter markers in the statement
   string of a PREPARE statement.
 

3  path_or_file
   Path-or-file is a placeholder used in LSE templates as an
   expansion of the attach-clause, alter-database-clause and create-
   database-clause placeholders.

   You can expand the path-or-file placeholder to the syntax
   FILENAME file-spec and PATHNAME path-name. See the online help
   for FILENAME and path_name, located at this level, for more
   information on those topics.
 

3  path_name
   A data dictionary path name can be:

   o  A full path name, such as CDD$TOP.MOLLY.SQL.PERSONNEL

   o  A relative path name

   o  A logical name for a full or relative path name

   Unless you use the PATHNAME argument in the CREATE DATABASE
   statement, SQL does not use the data dictionary to store data
   definitions.

   If you specify the PATHNAME argument when you first create a
   database, SQL creates a path name that contains copies of data
   definitions for the database.
 

3  quoted_string
   A quoted character string literal is a string of printable
   characters enclosed in single quotation marks. The maximum length
   of a character string is 1,024 octets. An unqualified character
   string must contain characters only from the literal character
   set of that session.

   The printable ASCII characters consist of:

   o  Uppercase alphabetic characters:

      A-Z

   o  Lowercase alphabetic characters:

      a-z

   o  Numerals:

      0-9

   o  Special characters:

      ! @ # $ % ^ & * ( ) - _ = + ` ~

      [ ] { } ; : " \ | / ? > < . ,

   For a list of the printable characters for MCS, see the OpenVMS
   documentation; for a list of printable characters for the other
   supported character sets, see the standard for that character
   set.
 

3  database_id
   Database-id is a placeholder used in LSE templates. Database-id
   expands to the placeholders ALIAS alias-name, FILENAME file-spec,
   and PATHNAME path-name. See the online help for FILENAME and
   path_name, located at this level, for more information. See the
   Aliases HELP topic under the top-level topic User_Supplied_names
   for more information on aliases.