This chapter contains general information for working in the Ingres Net environment. It explains how to connect to remote databases and which SQL commands are valid with Ingres Net. This chapter also includes a general discussion of how the system perceives you, the user, when you are working in a remote database.
In general, Ingres Net provides users with transparent access to remote databases. It is only when the connection is first established that you must specify the node on which the database resides and, in some circumstances, the type of server. After you are connected, you can work in the database as if it were local; no further reference to its location is necessary.
Note: If a default remote node is defined on the local instance, you do not have to specify a vnode name when you make a connection to that node. For information about using this feature, see Default Remote Nodes.
The syntax for accessing a remote database through an operating system-level command is:
command vnode::dbname[/server_class]
where:
Is any command used to invoke an Ingres tool, such as cbf, vcbf, sql, qbf or rbf.
Is the remote node on which the database is located. The two colons are required.
The remote node can be specified as either of the following:
Is the virtual node name 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. For the format of @host+, see Dynamic Vnode Specification.
Is the name of the database.
Is the type of server being accessed at the remote site. For a list of server classes, see Server Classes.
Example:
This command runs the terminal monitor (sql) and connects using vnode "production" to the customerdb database:
sql production::customerdb
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 Network Protocol Keywords.
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. Vnode attributes are described in Configure Vnode Attributes.
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
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:
Indicates DBMS Server
Indicates Star Server (Ingres Ingres Star)
Indicates EDBC for DB2
Indicates Enterprise Access for DB2 UDB
Indicates Enterprise Access for Rdb
Indicates EDBC for IMS
Indicates Ingres RMS Access
Indicates EDBC for VSAM
Indicates Enterprise Access for MS SQL
Indicates Enterprise Access for Oracle
Indicates Enterprise Access for Informix
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.
If you are using the connect statement in an application, connect to a database on a remote instance using the following syntax:
exec sql connect 'vnode::dbname[/server_class]'
Note: The vnode can be either a vnode name or a dynamic vnode specification (@host+).
You must use the single quotes around the designation of the vnode and database names (and server class, if applicable). For example, assume that you have an application residing on "napoleon" that wants to open a session with the database "advertisers" on "eugenie." The following statement performs this task (assuming also that "lady" is a valid vnode name for "eugenie"):
exec sql connect 'lady::advertisers';
Note that a server class is not specified in this statement; therefore the default server class defined on "eugenie" is used.
If the target database is accessed through an Enterprise Access or EDBC products, be sure to include the appropriate keyword for the server class. For example:
exec sql connect 'lady::advertisers/db2';
If the target database is accessed through Ingres Star, be sure to include the appropriate keyword for the server class. For example:
exec sql connect 'lady::advertisers/star';
When you are working over Ingres Net, you can use the -u flag with a command to imitate another user provided the User ID that you are working under on the remote node has the SECURITY privilege.
You can run any of the following Ingres commands against a remote database:
abf |
imageapp |
report |
---|---|---|
accessdb |
ingmenu |
sql |
compform |
isql |
sreport |
copyapp |
netutil |
unloaddb |
copydb |
printform |
upgradedb |
copyform |
qfb |
upgradefe |
copyrep |
query |
vifred |
dclgen |
rbf |
vision |
Note: The optimizedb command works across Ingres Net only if the client and server machines have identical architectures. Do not use this command across Ingres Net if the client and server have different architectures.
You cannot run the following Ingres commands against a remote database:
createdb |
destroydb |
iimonitor |
iinamu |
lockstat |
logstat |
statdump |
sysmod |
usermod |
verifydb |
|
|
For additional information on commands, see the Command Reference Guide.