The following parameters and flags are common to many commands. Each command description in this guide shows whether these parameters or flags are valid for that command.
The following syntax is typical for many commands:
command dbname|vnode::dbname[/server_class] [-fproduct]
[-uusername] [-Ggroupid] [-Rroleid] [other flags] [other parameters]
Identifies the name of a database. This parameter must precede all other non-flag parameters (with the exception of vnode::dbname).
Identifies the remote node on which the database is located. It must be followed by two colons (::) and the dbname parameter, with no intervening space.
The remote node can be specified as either of the following:
Is the virtual node name, as defined to Ingres Net, that points to the connection data and authorization data necessary to access a particular remote instance.
Is a "dynamic vnode" connection string that includes the connection data, user authorization, and attributes that are associated with a remote node. The format of @host+ is described in Dynamic Vnode Specification.
Specifies the name of one of the Ingres servers or Enterprise Access products (for example, DB2 UDB). If you are accessing a distributed database or a non-Ingres database through an Enterprise Access product, you must specify the server_class. For valid values for server_class, see the Connectivity Guide or your Enterprise Access product documentation.
Specifies the name of a product parameter. In selected commands, the catalog modules for one or more products may be specified. The user interface catalogs are grouped into modules. Each Ingres tool requires a set of modules to operate. If you omit the product, the command reads the installation's authorization string and specifies all products that the authorization string permits.
The product parameter must be one of the following:
Processes catalogs for the Ingres tools (Applications-By-Forms, Query-By-Forms, Report-By-Forms, and Visual Forms Editor).
Processes catalogs for DBD.
Processes catalogs for Vision.
Processes catalogs for OpenROAD.
Directs the command not to process catalogs for any user interface products. You cannot use the nofeclients name in conjunction with the name of any valid user interface product; nofeclients is valid only in specified commands.
Specifies the effective user name for the session. Valid only for a privileged user, DBA, or sessions that have the db_admin database privilege. (Some commands, including ckpdb, rollforwarddb, verifydb, createdb, and destroydb, restrict the use of the -u flag to privileged users.)
Note: The -u flag does not assume the group of the effective user. Use the -G flag to distinguish between the real and effective user.
Specifies the group identifier for the session. After the system administrator defines a group identifier, a DBA can grant database permissions to the group. When you issue a command, specifying group ID (using the -G flag), the group's permissions are applied to the session.
To specify a group, you must be a member of the specified group identifier's user list, a system administrator, the DBA of the specified database, or a user that has the db_admin privilege.
If you omit this flag and there is a default group identifier specified for you, the default group identifier is assigned to the session. (Default group identifiers are assigned using accessdb.)
VMS: You must enclose this parameter in double quotation marks ("Ggroupid"). 
Specifies the role identifier for an application image. After the system administrator defines a role identifier, a DBA can grant database permissions to the role ID. When you invoke an application and specify role ID (using the -R flag), the role permissions are applied to your session.
The roleid must be an existing role identifier. If the role identifier requires a password, you are prompted for the password. If you specify the -R flag, but omit both the role identifier and password, you are prompted for both. If no password is defined for the specified roleid, press the Enter key when prompted for the password.
Neither roleid nor password is validated if you are a system administrator, DBA for the specified database, or a user that has the db_admin privilege.
VMS: You must enclose this parameter in double quotation marks ("Rroleid"). 
For further information on groups and roles, see the Database Administrator Guide.
When connecting to a remote node, you can specify a dynamic vnode instead of a vnode name. The dynamic vnode specification includes the connection data, user authorization, and attributes that are associated with a remote node.
Note: A dynamic vnode can be used wherever a vnode is allowed, unless otherwise stated.
A dynamic vnode specification has the following format:
@host,protocol,port[;attribute=value{;attribute=value}][[user,password]]
Identifies the network name or address of the node on which the remote database is located. The @ character is required because it identifies this specification as a dynamic vnode rather than a vnode name.
Identifies the network protocol to be used by the local node to connect to the remote node. For a list of protocols and their associated keywords, see the Connectivity Guide.
Identifies the listen address of the Ingres instance on the remote node.
(Optional) Is one or more additional connection, encryption, and authentication attributes for the connection. For a description of each attribute and its possible values, see the Connectivity Guide.
Identifies the user (login) name on the remote system.
Is the password for the user on the remote system.
Note: The user and password are optional for a dynamic vnode, but must be enclosed in brackets if used.
Examples of dynamic vnode specification:
This command runs the terminal monitor (sql) and connects to node hosta using protocol tcp_ip to remote Ingres symbolic port II. The login and password are Johnny and secretpwd. The remote database name is customerdb:
sql @hosta,tcp_ip,II[Johnny,secretpwd]::customerdb
This command does the same as the previous example and uses an attribute to set up a direct connection:
sql @hosta,tcp_ip,II;connection_type=direct[Johnny,secretpwd]::customerdb
Flags that must be entered in uppercase may need special input syntax when the host operating system is case-insensitive.
Windows: The Windows operating system passes uppercase flags with no special formatting needed. For example, to invoke Interactive Terminal Monitor with a group of sales, you could enter:
isql dbname -Gsales 
UNIX: UNIX is case-sensitive and passes uppercase flags with no special formatting needed. For example, to invoke Ingres Menu with a group of sales, you could enter:
ingmenu dbname -Gsales 
VMS: OpenVMS is case-insensitive and requires the addition of double-quotation marks around the uppercase flags. In OpenVMS, you must enclose all uppercase Ingres flags in double quotation marks. For example, to invoke Ingres Menu with a group of sales, use double quotes around the -G designation:
ingmenu dbname "-Gsales"
A schema is a collection of database objects, such as tables. Each table, view, and synonym belongs to a schema that is determined when the object is created. The schema name corresponds to the user who owns the object. The schema name allows you to distinguish between objects with identical names but different owners.
You can specify a schema name for a table, view, or synonym on the command line to specify ownership. You use the following syntax:
schema.objectname
The period (.) must immediately follow the schema name and precede the object name, with no intervening spaces. Both the schema name and the object name can be delimited identifiers.
For example, to specify the table named "empinfo" having a schema name of dave, you would specify the table name as:
dave.empinfo
You do not use a schema name when referencing a table, view, or synonym; for example, you specify the table name as:
empinfo
The search looks first for an object with a schema corresponding to the current user; then it looks for an object owned by the DBA to which you have access. Lastly, if the object name begins with ii, the search looks for a system catalog with that name. For more information on schemas, see the Database Administrator Guide.
Delimited identifiers are database object names that are identical to reserved words, words that contain spaces, and non-alphanumeric characters that are disallowed in a regular identifier. If the installation allows mixed case names, you can also use delimited identifiers to distinguish among identical names with different case (for example, SALES and Sales).
On the command line, you use delimited identifiers if needed for names of tables, views, synonyms, schema, and authorization names (users, groups, and roles). For more information on allowable characters in delimited identifiers, see the SQL Reference Guide.
To create a delimited identifier, you must enclose the name in double quotation marks ("), dereference any embedded quotes, and use the appropriate number and type of delimiting quotes to pass it through your operating system. Use delimited identifiers on the operating system command line to specify database object names:
report my_database "Jane's table"
You must observe any operating system requirements for specifying quoted parameters, parameters containing embedded quotes, and parameters containing other characters that could be interpreted differently by the operating system. Depending on your operating system, you add delimiting and dereferencing quotes to a delimited identifier on the command line in order to pass it through the operating system with its own delimiting and embedded quotes (if any).
The following examples use the table names shown here:
Table Stored in Database |
Delimited Identifier |
Jane's table |
"Jane's table" |
"Expert" Table |
"""Expert"" Table" |
Windows: Surround delimited identifiers and their delimiting quotes with double quotes on the command line, and dereference the delimited identifier quotes, preceding them with a backslash (\):
report my_database "\"Jane's table\""
report my_database "\"\"\"Expert\"table\""
UNIX:
Bourne shell:
Surround delimited identifiers and their delimiting quotes with double quotes on the command line, and dereference the delimited identifier quotes, preceding them with a backslash (\):
report my_database "\"Jane's table\""
report my_database "\"\"\"Expert\"\" table\""
C shell:
Delimit all delimited identifier quotes and all other special shell characters, such as single quotes ('), spaces ( ), and colons (:), preceding them with a backslash (\):
report my_database \"Jane\'s\ table\"
report my_database \"\"\"Expert\"\" table\"
In some cases, strings contained inside delimited identifiers that contain special characters can be surrounded by double quotes instead:
report my_database \""Jane's table"\"
VMS: Surround delimited identifiers with a set of dereferenced double quotes on the command line. Also, you must dereference each embedded quote by doubling it (including any quotes required to dereference an embedded quote):
report my_database """Jane's table"""
report my_database """""""Expert"""" table"""
You can use delimited identifiers to specify a username for the
-u flag, a groupid parameter for the –G flag, or a roleid for the –R flag on the command line. A general example is:
sreport my_database myfile –u"user 5" –G"group 2"
Here are specific examples:
Windows:
sreport my_database myfile –u'"user 5"' –G'"group 2"'
Windows NT:
sreport my_database myfile –u'"user5'""-G'"group 2'"
UNIX:
sreport my_database myfile –u'"user 5"' –G'"group 2"'
VMS: In OpenVMS, you must also enclose the entire –Ggroupid parameter in double quotes:
sreport my_database myfile–u"""user 5""""-G"""group2""""
By default, identifiers are forced to lowercase, and are therefore case-insensitive. The casing rules can be specified at installation time for delimited identifiers. The following settings are allowed:
If complying with ISO Entry SQL-92 standards, the system administrator should set delimited identifiers to mixed case.