Database Access Syntax--Connect to Remote Database
The syntax for accessing a remote database through an operating system-level command is:
command [auth_user] vnode::dbname[/server_class]
where:
command
Is any command used to invoke an Ingres tool, such as cbf, vcbf, sql, qbf or rbf.
auth_user
Specifies the user name and password used for connection authentication, whether through OS authentication, DBMS authentication, or another mechanism. This syntax is useful when using DBMS authentication because it allows password entry or prompting with simplified syntax.
The auth_user can be one of the following:
+user
Prompts for the password of the user.
+user=username
Connects as the specified user and prompts for password.
+user=username,password
Connects as the specified user and password. Password is exposed on the command line.
@[username, password]
Connects as the specified user and password. Password is exposed on the command line.
Note: The @[username,password] must be specified as part of the full database name including vnode. No arguments can appear between it and the node name. For example:
sql -F8f20.10 @[me,mypassword]nodename::mydb
vnode::
Is the remote node where the database resides. The two colons are required.
The remote node can be specified as either of the following:
vnode_name
Is the virtual node name that points to the connection data and authorization data necessary to access a particular remote instance.
@host+
dbname
Is the name of the database.
server_class
Is the type of server being accessed at the remote site. For a list of server classes, see
Server Classes.
Examples:
Start the terminal monitor (sql) and connect using vnode "production" to the mydb database:
sql production::mydb
Connect as the logged in OS user. Prompt for the password:
sql +user production::mydb
Connect as user fred, and prompt for the password. Fred need not be an OS user:
sql +user=fred production::mydb
Connect as user fred and enter the password on the command line. Fred need not be an OS user:
sql +user=fred,secret production::mydb
Connect as user fred and enter the password on the command line. Fred need not be an OS user.
sql '@[fred,secret]production::mydb'
Dynamic Vnode Specification--Connect to Remote Database
When connecting to a remote database (using the vnode::dbname syntax), 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]]
UNIX: Enclose the semicolon in single or double quotes (so it will not be treated as a command terminator). Alternatively, place the entire dynamic vnode specification in single or double quotes.
@host
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.
protocol
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
Network Protocol Keywords.
port
Identifies the listen address of the instance on the remote node.
attribute=value
(Optional) Is one or more additional connection, encryption, and authentication attributes for the connection. Vnode attributes are described in
Configure Vnode Attributes.
[user,password]
(Optional) Identifies the user name and password on the remote system.
Note: The user name and password must be enclosed in brackets.
Rather than specifying [user, password] in the dynamic vnode specification, you can use the +user username syntax before the dynamic vnode specification. The +user flag prompts for the password, which protects the password from exposure. For example:
sql +user=johnny @machine01,tcp_ip,II::inventory
If the +user flag is used, you cannot also specify the [user, password] option as part of the dynamic vnode.
Examples of dynamic vnode specification:
Run the terminal monitor (sql) and connect 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
UNIX: sql '@hosta,tcp_ip,II;[Johnny,secretpwd]::customerdb'
Establish a direct connection by using the connection_type attribute:
sql @hosta,tcp_ip,II;connection_type=direct[Johnny,secretpwd]::customerdb
UNIX: sql '@hosta,tcp_ip,II;connection_type=direct[Johnny,secretpwd]::customerdb'
Start the terminal monitor, connect to node myhost01 as user johnny using TCP-IP protocol (the default), and prompt for the password:
sql +user=johnny @myhost01,II::customerdb
Server Classes
If you do not specify a server class when connecting to a database, Ingres assumes a default. The default is the value in default_server_class on the remote instance (ingres, unless defined otherwise).
Valid Ingres server classes are as follows:
ingres
Indicates DBMS Server
star
Indicates Star Server (Ingres Star)
db2
Indicates EDBC for DB2
db2udb
Indicates Enterprise Access for DB2 UDB
rdb
Indicates Enterprise Access for RDB
ims
Indicates EDBC for IMS
rms
Indicates Ingres RMS Access
vsam
Indicates EDBC for VSAM
mssql
Indicates Enterprise Access for MS SQL
oracle
Indicates Enterprise Access for Oracle
informix
Indicates Enterprise Access for Informix
sybase
Indicates Enterprise Access for Sybase
To view or change the default server class value, use the Configure Name Server screen of the Configuration-By-Forms (cbf) utility, or the Parameters Page, Name Server Component in Configuration Manager (vcbf).
The server class for the DBMS Server (default is ingres) and Star Server (default is star) can also be changed. This is typically done to distinguish between multiple DBMS or Star servers that have different sets of parameters, so that users can connect to a specific server using an assigned server class name.
Additional server types are added to this list as additional Enterprise Access or EDBC products are developed. Check the Readme file for the most up-to-date set of products.