Connect_example2 Application
This directory contains an example of a client/server application that shows various ways of using dynamic virtual nodes (vnodes) to access Ingres and Enterprise Access servers. It uses the local Loadnrun Standalone Net Client.
Description
The connect_example2 application illustrates how to build and use a Dynamic Vnode connection. This technique enables the application to prompt for a user ID and password that can override this information in a vnode. Dynamic Vnodes can supply all the information needed to connect to an Ingres Server (hostname, listen address, protocol, userid, password, connection attributes), or it can be used to override this information in an existing vnode.
Dynamic Vnode Description
A connection string can contain information that identifies whether the connection is to be established to a local server or to a remote server. This information is obtained using the vnode component of the connection string and by accessing the local Ingres Name Server to retrieve the connection information.
Ingres 2.5 introduced the ability to specify or override the contents of a vnode in a database. This capability is identified when the DBSession database name starts with the"@" character.
The client application requests a session with a server by specifying the logical name of the partner with which it wishes to establish a connection. The partner name is a null-terminated character string with the following syntax:
[node::][dbname][/server]
node
addr{;attr}[auth] | @auth
addr
vnode | @host[,protocol,port]
attr
attribute = value
auth
"["username,password"]"
server
server_class | @address
where:
vnode
Specifies a virtual (or logical) node, which has been defined to the local GCF Name Service and identifies where the remote database is located. See the Ingres Connectivity Guide for information about how to define virtual nodes.
host,protocol,port
Specifies a host network name indicating the target machine, the protocol to be used, and the network listen address (port) of the remote installation. The configured browsing registry protocol and port are used if only the host is provided.
attribute = value
Specifies connection attributes and associated values that will override virtual node information (if a vnode is specified) or be applied to the remote connection (if a host is specified).
username,password
Specifies the user ID and authorizing password to be used to establish the connection. Overrides virtual node login information for remote connections. Validated by local Ingres Name Service if neither host nor vnode is specified.
dbname
Identifies the target database.
server_class
Specifies the class of server to handle the request. This value is optional and can have one of the following values: INGRES, MSSQL, DB2UDB, ORACLE, RMS, RDB, SYBASE, INFORMIX, IMS, DB2, IDMS, DCOM, VSAM, or STAR. User-defined server classes are allowed to be specified as well.
If the node component is not provided, the connection will be established with a server in the current installation. The database component may be omitted if the server component targets a server that does not require the component. If the server component is omitted, the default server class configured for the local Name Service will be used.
If any of these components contains a character that is not legal in an Ingres database name, the component must be enclosed within double quotes ("). Double quotes within a component must occur in pairs ("").
If a connection request is made using a vnodeless connection string with the Ingres II 2.0 client runtime, the following error messages will be received:
E_LC0001 GCA protocol service (GCA_REQUEST)
failure. Internal service status E_GC0132 --
User provided a vnode as part of the database
name (vnode::dbname), but connection information
for that vnode is missing. Enter connection
information for the vnode using NETUTIL.
E_LQ0001 Failed to connect to DBMS session.
OpenROAD returns the following error if a connection error occurs or if the Ingres client is 2.0 or earlier:
E_LQ0001 Failed to connect to DBMS session.
E_LC0001 GCA protocol service (GCA_REQUEST)
failure. Internal service status E_GC0132 --
User provided a vnode as part of the database
name (vnode::dbname), but connection information
for that vnode is missing. Enter connection
information for the vnode using NETUTIL.
E_WT0029 Error at line n of component.
E_OM0040 Couldn't open database.
'@hostname,protocol,port[username,********]::dbname/class'.
The database '@hostname,protocol,port[username,********]::dbname/class'
could not be opened. A subsequent error should
give more information about why the database could
not be opened. If no subsequent error is given,
check the spelling of the database name and make
sure that you can access it.
Before OpenROAD displays this error message, it searches the database string that was supplied by the application and suppresses any references to the password that was supplied.
Forcing the use of Loadnrun Client 6.2 runtime
The following directive forces the use of the Loadnrun 6.2 Client runtime if the application is launched by the Loadnrun60.bat or Loadnrun51.bat script:
ENVIRONMENT=PATH=%II_ECLIENT_APPDIR%bin;%II_LOADNRUN62_ROOT%\bin;%PATH%
Contents of the subdirectory
• connect_example2.img
• install4gl.txt
Contents of connect_example2\install4gl.txt
//
// The following control statements must not start on line 1.
//
4GLVERSION =6,20,14001,0
IMAGEFILE =connect_example2.img
CMDFLAGS =-Tyes
//
// The following environment variables are set by the run.bat that is generated
// by Loadnrun when an application is downloaded from the server
//
// Environment Variable Value
// -------------------- -----
// II_ECLIENT_ROOT %APPDATA%\Actian\eclientcache\[HOSTSYSTEM]\[HOSTSUFFIX]\
// LOADNRUN_CLIENT_ROOT %II_LOADNRUN51_ROOT%\ (if launched using LOADNRUN51.bat)
// LOADNRUN_CLIENT_ROOT %II_LOADNRUN60_ROOT%\ (if launched using LOADNRUN60.bat)
// LOADNRUN_CLIENT_ROOT %II_LOADNRUN62_ROOT%\ (if launched using LOADNRUN62.bat)
// II_ECLIENT_RUNMODE 2
// II_ECLIENT_URL [HOSTSYSTEMURL]
// II_ECLIENT_VERSION
// II_ECLIENT_4GLVERSION [INSTALL4GLVERSION]
// II_ECLIENT_SUFFIX [HOSTSUFFIX]
// II_ECLIENT_APPDIR %II_ECLIENT_ROOT%[APPNAME]
// II_ECLIENT_LIBDIR %II_ECLIENT_ROOT%lib
// II_W4GLAPPS_SYS %II_ECLIENT_ROOT%lib
// II_W4GLAPPS_DIR %II_ECLIENT_ROOT%[APPNAME]
// II_LOG %II_ECLIENT_ROOT%[APPNAME]
// II_ECLIENT_SYSTEM %windir%\syswow64 (on 64-bit systems)
// II_ECLIENT_SYSTEM %windir%\system32 (on 32-bit systems)
// PATH %II_ECLIENT_ROOT%qt;%LOADNRUN_CLIENT_ROOT%bin;%PATH%
// II_LOADNRUN TRUE
//
// where the following are defined
//
// String Name String Value Description
// ----------- ------------------------
// [HOSTSYSTEMURL] This is the URL that is passed when Loadnrun is invoked on
// the Client
// [HOSTSYSTEM] This is the system name that is hosting the [HOSTSYSTEMURL]
// [HOSTSUFFIX] This is the suffix that is passed when Loadnrun is invoked
// on the client
// [INSTALL4GLVERSION] This is the value of the 4GLVERSION directive located in
// the install4gl.txt
// [APPNAME] This is the application name passed when Loadnrun is invoked
// on the Client
//
// An example of the command that will be invoked is as follows
//
// loadnrun62.bat [APPNAME] [HOSTSYSTEMURL] [HOSTSUFFIX]
//
// The following ENVIRONMENT directives will be used to append SET statements in
// the run.bat that will be generated by Loadnrun. These can override any environment
// variables generated in run.bat prior to the launch of the application.
//
// Force the use of the Loadnrun 6.2 client runtime for run.bat
//
ENVIRONMENT=PATH=%II_ECLIENT_APPDIR%bin;%II_LOADNRUN62_ROOT%\bin;%PATH%
//
// Environment for Application
//
ENVIRONMENT=II_SYSTEM=%II_LOADNRUN62_ROOT%
ENVIRONMENT=PATH=%II_SYSTEM%\ingres\bin;%II_SYSTEM%\ingres\utility;%PATH%
ENVIRONMENT=OR_CONFIG=%II_ECLIENT_APPDIR%