Database Connections | DB2(R) Universal Database for OS/390 V7.1 Application Certification Guide (IBM DB2 Certification Guide Series)


Team-Fly

	DB2 Universal Database for OS/390 v7.1 Application Certification Guide By Susan Lawson
	Table of Contents

	Chapter 11. ODBC/CLI Programming

Database Connections

Connections to DB2 ODBC data sources are controlled with connection handles. Prior to connecting, a connection handle must be allocated. The program must execute on a system with a running DB2 for OS/390 and z/OS subsystem, though that subsystem doesn't have to be the desired data source.

Connecting

ODBC programs can connect to local DB2 subsystems, remote DB2 subsystems, or remote DRDA application servers. Each connection requires a separate connection handle. Remote connections require that the server be defined in the communications database of the local DB2 subsystem.

The SQLConnect() or SQLDriverConnect() functions are used to establish the connection to DB2. Both functions require a connection handle and a connection string. The connection string defines the target data source (DB2 subsystem) for the connection. The connection string can specify a DataSourceName or omit it in order to establish a null connection (discussed below).

Some connection attributes must be set prior to SQLConnect() execution. An example of this is the connection type (SQL_ATTR_CONNECTTYPE), which controls whether this is a type 1 or type 2 connection.

 SQLRETURN SQLConnect (SQLHDBC     ConnectionHandle,                        SQLCHAR    *DataSourceName,                       SQLSMALLINT DataSourceLength,                       SQLCHAR    *Userid,                       SQLSMALLINT UseridLength,                       SQLCHAR    *Password,                       SQLSMALLINT PasswordLength);

SQLConnect() issues a SQL CONNECT to the data source specified by DataSourceName. The Userid and Password fields are validated , but ignored. Data source attribute values are loaded from the ODBC initialization file if there is a section.

 SQLRETURN SQLDriverConnect (SQLHDBC      ConnectionHandle,                              SQLHWND      hwnd,                             SQLCHAR     *ConnStringIn,                             SQLSMALLINT  ConnStringInLength,                             SQLCHAR     *ConnStringOut,                             SQLSMALLINT  ConnStringOutMaxLen,                             SQLSMALLINT *ConnStringOutActLen,                             SQLUSMALLINT DriverCompletion);

SQLDriverConnect() takes a more complicated ConnectStringIn that contains keyword and value pairs. The data source name is specified with the DSN keywordfor example, DSN=DB01. On other platforms, SQLDriverConnect() has options that permit the ODBC drivers to prompt the user for additional information. This is often used to let the driver prompt the user for his or her user ID and password as part of the connection rather than the application writing its own prompt dialog box. DB2 for OS/390 and z/OS does not support these prompting options. The connection string passed into the SQLDriverConnect() function usually looks something like DSN=DBT1,UID=MYID,PWD=MYPASS. DB2 for OS/390 and z/OS ignores the UID and PWD keywords. Additional keywords can be specified to override the specification in the initialization file.

Null Connections

A null connection is established by issuing SQLConnect() with a null data source name pointer or a zero data source name length. An application would need a null connection when running as a stored procedure or when mixing embedded SQL with ODBC and the connection has already been established.

An application that wants to connect to the default data source should also use a null connection. DB2 will pull the default DB2 subsystem from the MVSDEFAULTSSID setting in the initialization file.

For a null SQLConnect(), the connection type defaults to the value of the CONNECTTYPE keyword specified in the common section of the initialization file. Before the null SQLConnect() is issued, the connection type can be overridden by specifying the SQL_ATTR_CONNECTTYPE attribute.

Remote Connections

In order to connect to a remote DRDA application server, that server must trust the user ID supplied by DB2 for OS/390 and z/OS. This is because DB2 for OS/390 and z/OS does not support the specification of user ID and password on the SQL CONNECT statement.

Disconnecting

After a program is done processing, it should call SQLDisconnect() to terminate the database connection.

 SQLRETURN SQLDisconnect (SQLHDBC ConnectionHandle);

The connection should be terminated prior to releasing the connection handle. Once the connection is terminated , the program can, if desired, reuse the connection handle to open a new connection to the same or another data source.


Team-Fly

Top