Copyright: DM 22Jan97


DataMiner Guide TOC
IDL DataMiner Guide

This help file contains the IDL DataMiner Guide.

NOTE:

This is beta-test documentation. Both the text and the hypertext coding are still in flux. Feel free to make comments on the current contents, but realize that it is not yet complete and will change significantly before the final release of IDL 5.0.


IDL DataMiner Guide

Select "Contents," "Keyword Search," or "Text Search" from the

Navigate menu, or click the "Help Topics" button, for more

navigational aids.


Overview

The IDL DataMiner is an Open Database Connectivity (ODBC) interface that allows IDL users to access and manipulate information from a variety of database management systems. Research Systems developed IDL DataMiner so that IDL users can have all the connectivity advantages of ODBC without having to understand the intricacies of ODBC or SQL (Structured Query Language).

Note	SQL is ODBC's standard for accessing data and is a widely accepted industry standard for data definition, data manipulation, data management, access protection, and transaction control. The IDL DataMiner was designed so that users would not be required to have a knowledge of SQL to access data sources. However, DataMiner does provide an execution routine which allows users to perform any valid SQL statement (including creating, retrieving, and deleting tables in a database).

Because DataMiner features a consistent, database-independent API for database connections, the number of databases available is limited only by the number of ODBC drivers available.

DataMiner Functionality

The IDL DataMiner allows you to perform actions including the following:

•	Connect to a database management system (DBMS)

•	Query data from a DBMS

•	Get information about the available database tables in a DBMS

•	Access a table in a DBMS

•	Create a table in a DBMS

•	Delete a table in a DBMS

•	Perform standard SQL operations in the DBMS

•	Get information about the columns in a selected table

•	Add/Change/Delete records in a table

About this Volume

The IDL DataMiner Guide describes IDL's ODBC interface. Information about specific ODBC drivers is located in the Visigenic ODBC DriverSet Reference Manual, which is included in the DataMiner package. The Visigenic manual is also included in PostScript and Adobe Acrobat format files on the IDL CD-ROM. See the "readme" file in the info directory of the IDL CD-ROM for details.

IDL Online Help

IDL's Online Help system gives you access to this volume in electronic, hypertext-linked format. You can enter the Online Help system by entering ? at the IDL command prompt or by selecting "Online Help" from the Help menu of the IDL Development Environment.

Audience

This manual assumes you have:

•	a working knowledge of IDL,

•	knowledge of your own DBMS.

Familiarity with SQL is helpful, but not required.

Organization

The IDL DataMiner Guide is divided into the following chapters:

♦	Chapter 1, (this chapter) discusses the manual's intended audience, organization of the manual, conventions, and lists other sources of information about ODBC.

♦	Chapter 2, "Using IDL DataMiner," discusses IDL DataMiner functionality.

♦	Chapter 3, "The DataMiner API," is a reference explaining the IDL DataMiner object classes and their use.

♦	Chapter 4, "DriverSet Basics," introduces the ODBC DriverSet, explains the API and SQL grammar conformance levels, and provides information about how to access translation libraries with the drivers.

♦	Chapter 5, "Understanding the ODBC.INI File," explains the ODBC initialization file and its contents.


Conventions

This section describes the conventions used in this manual to identify technical terms and computer language constructs.

Terminology

The following are terms that are used throughout this manual:

DMBS: Database Management System

DATASOURCE: A specific instance of a combination of a DBMS product, any remote operating system, and network necessary to access the DBMS.

RECORDSET: A subset of the records in the current database. Recordsets are created either by formulating an SQL query to select records or by selecting an existing named table in the database.

CURSOR: The current location or current record in a recordset.

Typographical conventions

Table 1-1: Typographic Conventions.

Convention	Used for
Bold type	Bold type indicates that syntax should be typed exactly as shown. For UNIX, bold type is used to indicate database names, filenames, and similar terms.
Courier type	In examples or program listings, things that you must enter at the command line or in a file are displayed in courier type. Results or data that IDL displays on your computer screen are shown in courier bold type.
UPPER CASE	IDL or SQL statements, functions, procedures, and keywords are displayed in UPPER CASE type. For example, the calling sequence for an IDL procedure looks like this: CONTOUR, Z [, X, Y] For Windows, UPPER CASE type is used to indicate database names, filenames, and similar terms.
Italic type	Arguments to IDL procedures and functions —data or variables you must provide — are displayed in italic type. In the above example, Z, X, and Y are all arguments.
[]	Square brackets are used in calling sequences indicate that the enclosed arguments are optional. Do not type the brackets. For example: [ODBC Data Sources] indicates that the term is optional.
Mixed Case	IDL object class and method names are displayed in Mixed Case type. For example, the calling sequence to create an object and call a method looks like this: object = OBJ_NEW('IDLdbDatabase')
Platform Conventions

This manual uses symbols to represent different platforms. As shown in the following example, the diamond bullet followed by a platform name in boldface indicates that a certain bullet, table row, syntax element, or paragraph is specific to the platform specified.

♦	WINDOWS


Where to Find Additional Information

For more information about ODBC, refer to one or more of the following:

•	ODBC DriverSet Help. On Windows platforms, you can get additional information on the drivers installed on your system by clicking the "Help" button on the Setup and Connect dialogs. On UNIX platforms, individual man pages provide information about the various drivers.

Visigenic ODBC DriverSet Reference Manual. This manual describes various drivers and how to set up, configure, and use them so they can connect to data sources. This manual is included in the DataMiner package. In addition, the Visigenic manual is included in PostScript and Adobe Acrobat format files on the IDL CD-ROM. See the "readme" file in the info directory of the IDL CD-ROM for details.

For more information about the Open Database Connectivity (ODBC) interface, refer to one or more of the following guides:

•	ODBC for UNIX Programmer's Reference and ODBC for UNIX SDK Guide (Version 2.0). The ODBC for UNIX Programmer's Reference lists each of the functions in the ODBC API in alphabetic order and describes the functions in detail. The ODBC for UNIX SDK Guide provides installation instructions, introduces the ODBC architecture, and explains how to write ODBC drivers and applications that use the ODBC for UNIX SDK.

•	Microsoft ODBC Programmer's Reference and SDK Guide (Version 2.0). This programmer's reference introduces the ODBC architecture and explains how to write ODBC drivers and applications that use ODBC for Windows. It also contains the ODBC API Reference, in which each of the functions in the ODBC API is listed in alphabetic order and described in detail. The SDK guide explains how to install and use the SDK software.


Network Access Requirements

To access an external database, you must be able to connect to the network, have access to the external database, and have access to the server on which the external database is located. Database permissions are established using the security features of the external database. If you do not have the proper access permissions, consult your local database administrator.


Initialization

When you install IDL and the ODBC database drivers, default values are written into the ODBC initialization file. Your particular environment might require you to change entries or you might wish to change entries so that you only have to enter login and password information once. The IDL DataMiner allows you to enter common database sources and parameters for those databases in the initialization file. When you change your initialization settings, you must restart IDL for the changes to take effect. See Chapter 5, "Understanding the ODBC.INI File", for details.


Mappings

SQL data types have been mapped to IDL data types so that you can access and manipulate the data without having to fully understand SQL. Table 1-2 on page 6 details these mappings.

Table 1-2: IDL - SQL Type Code Mapping

IDL Type	SQL Type
STRING	DECIMAL
	NUMERIC
	BIGINT
	CHAR
	VARCHAR
	LONG VARCHAR
BYTE	BIT
	TINYINT
INT	SMALLINT
LONG	INTEGER
FLOAT	REAL
DOUBLE	FLOAT
	DOUBLE PRECISION
BYTE ARRAY	BINARY
	VARBINARY
	LONG VARBINARY
ODBC_SQL_DATE Struct	DATE
ODBC_SQL_TIME Struct	TIME
ODBC_SQL_TIMESTAMP Struct	TIMESTAMP


Error Messages

The error messages returned follow the ODBC standard error message format as outlined in the ODBC Software Development Kit. ODBC error messages use the following format:

[vendor-identifier] [ODBC-component-identifier]
[data-source-identifier] data-source-text, component-text

where

[vendor-identifier] shows the vendor of the component in which the error occurred, or that received the error directly from the data source.

[ODBC-component-identifier] shows the component in which the error occurred, or that received the error directly from the data source.

[data-source-identifier] shows the data source in which the error occurred.

data-source-text is the text generated by the data source, if the error occurred in a data source.

component-text is the text generated by the ODBC component, if the error occurred in an ODBC component.

For example, an error message from a data source might look like this:

"[Visigenic][ODBC Informix Driver][Informix] User's password
is not correct for the database server."

Or an error message from a Visigenic driver might look like the following:

"[Visigenic][ODBC ORACLE7 Server Driver] Duplicate cursor name"


Topics in Overview Chapter

About this Volume

Conventions

Where to Find Additional Information

Network Access Requirements

Initialization

Mappings

Error Messages


Using IDL DataMiner

This chapter describes the functionality and syntax of the IDL DataMiner.

For more detail on how to use IDL DataMiner classes to perform actions on a DBMS, see Chapter 3, "The DataMiner API". For information on IDL commands and syntax, see the IDL Reference Guide.


Components

The IDL DataMiner provides two IDL objects for accessing databases:

•	Database object (IDLdbDatabase)

•	Recordset object (IDLdbRecordset)

A full discussion of IDL objects is beyond the scope of this manual. Consult IDL Objects and Object Graphics for details about IDL's object-oriented programming features. Objects and Object Graphics is available both in print and as part of IDL's online help system.

The Database object contains instance data and methods that you can use to connect to, disconnect from, and perform operations on a DBMS. The Recordset object contains a database table or the results from a SQL query. You can use Recordset methods to manipulate table data.

Note	Some of the methods associated with IDL database and recordset objects are driver-dependent. This means that some functions are not available when you are using database drivers that do not support those functions.

The IDL DataMiner also provides an IDL function, DIALOG_DBCONNECT, that you can use to connect to the DBMS via the standard ODBC dialog boxes. Using this method, you are prompted for any information that is required to connect to the desired database.

Finally, the IDL function DB_EXISTS allows you to determine if database functionality is available on a specific platform.


Using the DBEXISTS function
Using the DB_EXISTS Function

The ODBC system is not available on all systems. Use the DB_EXISTS function to determine if a database is available on your system. To check whether ODBC is installed on your system, enter the following at the IDL prompt:

status = DB_EXISTS()

If the DataMiner and ODBC drivers are installed on your system, the DB_EXISTS function returns 1; otherwise the function returns 0.


Creating a Database Object

To connect to a database, you must first create an IDL Database Object using the following statement:

objDB = OBJ_NEW('IDLdbDatabase')

The newly-created database object represents a connection to a datasource. The object is not considered valid until a connection to the datasource is made, either via the Connect method of the IDL Database Object or the DIALOG_DBCONNECT function.

Once the Database Object has been created, you can perform operations including:

•	connecting to a database,

•	finding out which databases are available,

•	finding out if a specific database is available.

•	get properties of the database object.

Finding Available Databases

To find out which databases are available, use the database object's GetDatasources method as follows.

sources = objDB->GetDatasources()

The result is an array of IDL structures containing the datasource names and descriptions of all available data sources. See "IDLdbDatabase::GetDatasources" on page 27 for further information on this structure.

Finding a Specific Database

To find out if a specific database is available, inspect the list of datasources returned by the GetDatasources method. The following IDL commands check to see if "Informix" is listed in the array of data sources, and if so, print the word "Yes" to the IDL command log:

index = WHERE(sources.datasource EQ 'Informix', nmatch)

IF(nmatch ge 1) THEN PRINT, 'Yes'

If the desired database is available, you can connect to that database.


Connecting to a Database

Once you have created a Database object, you can connect to a database. IDL DataMiner offers two options for accessing databases:

1.	The DIALOG_DBCONNECT function and the ODBC dialog boxes.

2.	The Connect method of the IDL Database Object.

Connecting with the DIALOG_DBCONNECT Function

DIALOG_DBCONNECT is a function used to connect to a database using ODBC dialog boxes. These dialogs prompt you for information required to connect to the desired database.

To connect to a database using the DIALOG_DBCONNECT function, enter the following at the IDL prompt:

status = Dialog_DBConnect(objDB)

The SQL Data Sources dialog box appears. This dialog box lists the currently defined Data Sources; it looks something like this:

You can take one of three actions:

•	Select the desired data source and click "OK". After selecting this button, a "true" value is returned if the database object connects to the data source.

•	Cancel the operation by clicking "Cancel". After selecting this button, a "false" value is returned, and the database object does not connect to the data source.

•	Click "New" to define a new data source for the system. After selecting this button, the Add Data Source dialog box appears.

Define a new data source for the system by selecting the desired ODBC driver from the list and clicking the OK button. The dialog box will close and you will be connected to a database.

Connecting with the IDL Database Object's Connect Method

To connect to a database using the database object's connect method, enter the following at the IDL prompt:

objDB->connect, datasource = source_name

where source_name is the name of the data source. One way to specify the datasource name is to provide an index into the array of datasource names created with the IDL commands shown in "Finding Available Databases" on page 11, above. For example, if you wanted to connect to the first available datasource in the list of available sources, you might use the following IDL commands:

sources = objDB->GetDatasources()

mysource = sources(0).datasource

objDB->connect, datasource = mysource

Once you have connected to a database, you can find a table, connect to that table, and then work with that table's data.

Once you have connected to a database, you can perform several operations using IDL DataMiner methods. These operations include:

•	finding out which tables are available in the datasource;

•	finding specific tables in the datasource;

•	executing SQL statements to perform actions such as creating a table or deleting a table;

•	getting database properties;

•	creating tables;

•	creating a recordset and connecting to tables; and

•	retrieving and manipulating table data.


Finding Tables

Once you have connected to the database, you can get a list of available tables or find a specific table.

Finding Available Tables

To find out which tables are available, use the GetTables method of the database object:

tables = objDB->gettables()

Caution	The GetTables method is not available with all drivers.

The result is an array of IDL structures containing information about the available tables. See "IDLdbDatabase::GetTables" on page 29 for further information on this structure.

Finding Specific Tables

To find out if a specific table is available, inspect the list of tables returned by the GetTables method. The following IDL commands check to see if "mytable" is listed in the array of tables, and if so, print the word "Yes" to the IDL command log:

index = WHERE(tables.name EQ 'mytable', nmatch)

IF(nmatch ge 1) THEN PRINT, 'Yes'

You are now ready to connect to the table and retrieve data.


Connecting to a Table

Connecting to a table and retrieving its data involves:

•	creating a Recordset object,

•	specifying the table from which the information is being retrieved.

The recordset object contains a database table or a selection based on criteria you specify in an SQL query. This object allows you to programmatically manipulate the data in the database. To create this object, a valid database object is required.

In the following example, a new Recordset object is being created for a table called "mydata."

objRS = OBJ_NEW('IDLDBRecordset', objDB, table='mydata')

Once you have connected to a table, you can use DataMiner methods to manipulate the data in several ways as depicted in the examples provided in the next section.

Note	When a table is selected, the entire data contained in the table is not automatically imported into IDL. This preserves memory. You can retrieve the desired data in a recordset by moving the cursor to the desired record via the MoveCursor method and then importing that data into IDL using the GetField method.


Working with Table Data

Once you have created the Recordset object and connected to a table, you can use DataMiner methods to retrieve and manipulate the data in several ways. For example, you can:

•	find out if a table is "ReadOnly",

•	get properties of the recordset,

•	move the cursor,

•	add records,

•	delete records,

•	retrieve fields,

•	set fields,

•	find the current row number in a recordset,

•	find the number of columns in a recordset,

•	get an array of column information structures, one for each column in the recordset.

You can also obtain information about a database or recordset concerning the following:

•	the number of table columns,

•	the cursor name of a recordset (this can be used in an SQL statement if desired),

•	the name of DBMS associated with a database object,

•	the DBMS version,

•	a list of available drivers,

•	the ODBC driver level,

•	the ODBC driver version,

•	the maximum number of connections.

Moving through a Recordset

Moving through recordsets is based on the concept of the cursor. The cursor is the current row, or record, in the recordset. When you refer to fields in a Recordset, you obtain values from the current record, and only the current record can be modified.

You can use the Recordset object's MoveCursor method to navigate through the records in a recordset. Keywords to the MoveCursor method allow you to specify new cursor locations.

In the following example, the MoveCursor method and first keyword move to the first record.

objRS->MoveCursor, /first

In the following example, the MoveCursor method and next keyword move to the next record.

objRS->MoveCursor, /next

Example

The following example steps you through the process of creating a database object, connecting to a datasource, creating a table, and moving data between the database and IDL. The example uses the Microsoft SQL server; you will need to replace references to the Microsoft SQL server with references to your own specific database server. In order to work through this example, you will need to be able to connect to and log on to your database server.

First, create a database object. Enter the following at the IDL command prompt:

oDB = obj_new('IDLDBDatabase')

Use the GetDatasources method to discover the names of the datasources available on your system, the print the list to your command log window:

sources = oDB->GetDatasources()

PRINT, sources.datasource, FORMAT='(a)'

IDL will print something like the following:

SybaseDBLib

Sybase

Oracle

Ingres

Informix

MSSQLServer

Connect to the MS SQL server. (Substitute your own datasource, username, and password.)

oDB->Connect, DataSource = 'MSSQLServer', $

    user=username, password=passwd

Get a list of the available tables:

tables = oDB->GetTables()

PRINT, atables.name, FORMAT='(a)'

IDL will print something like the following:

sysalternates

sysarticles

syscolumns

syspublications

sysreferences

systypes

sysusers

mydata

Create a new table named "im_info" using SQL commands:

oDB->ExecuteSQL, $

    "create table im_info (id integer, x integer," + $

    "y integer, data image, name char(50))"

Now create a Recordset object and connect to the table you just created:

oRS = obj_new('IDLdbRecordSet', oDB, table='im_info')

Add a record to the object. This record contains four fields that describe an image: the width of the image, the height of the image, the image data itself, and the name of the image.

oRS->AddRecord, 400, 400, BYTSCL(DIST(400)), 'first image'

Move the current location in the table (the cursor position) to the first row:

oRS->MoveCursor, /FIRST

Retrieve the information from this record into IDL variables:

X = oRS->GetField(1)	;X size of image

Y = oRS->GetField(2)	;Y size of image

image = oRS->GetField(3)	;Image data

name = oRS->getField(4)	;Image name

Create an IDL window to display the image:

WINDOW, COLORS=-5, TITLE=name, XSIZE=x, YSIZE=y

Display the image:

TVSCL, image

Now, delete the im_info table and destroy the database objects:

oDB->ExecuteSQL, 'drop table im_info'

OBJ_DESTROY, oRS

OBJ_DESTROY, oDB


Topics in Using DataMiner Chapter
Topics in the Using DataMiner Chapter

Using the DB_EXISTS Function

Creating a Database Object

Connecting to a Database

Finding Tables

Connecting to a Table

Working with Table Data

Example


The DataMiner API

This chapter describes the IDL DataMiner functions, objects, and methods.

How to Use this Chapter

The functions, object descriptions, and method descriptions for the IDL DataMiner are documented alphabetically in this chapter. The page or pages describing each class include references to sub- and super-classes, and to the methods associated with the class. Class methods are documented alphabetically following the description of the class itself.

A description of each method follows its name. Beneath the general description of the method are sections that describe the calling sequence for the method, its arguments (if any), and its keywords (if any). These sections are described below.

Calling Sequence

The "Calling Sequence" section shows the proper syntax for calling the method.

Procedure Methods

IDL procedures have the calling sequence:

PROCEDURE_NAME, Argument [, Optional_Arguments]

where PROCEDURE_NAME is the name of the procedure, Argument is a required parameter, and Optional_Argument is an optional parameter to the procedure. IDL procedure methods have the calling sequence:

Obj -> PROCEDURE_NAME, Argument [, Optional_Arguments]

where Obj is a valid object reference, PROCEDURE_NAME is the name of the procedure method, Argument is a required parameter, and Optional_Argument is an optional parameter to the procedure method.

Note	The square brackets around optional arguments are not used in the actual call to the procedure; they are simply used to denote the optional nature of the arguments within this document.

Functions

IDL functions have the calling sequence:

Result = FUNCTION_NAME(Argument [, Optional_Arguments])

where Result is the returned value of the function, FUNCTION_NAME is the name of the function, Argument is a required parameter, and Optional_Argument is an optional parameter.

IDL function methods have the calling sequence:

Result = Obj -> FUNCTION_NAME(Argument [, Optional_Arguments])

where Obj is a valid object reference, Result is the returned value of the function method, FUNCTION_NAME is the name of the function method, Argument is a required parameter, and Optional_Argument is an optional parameter.

Note	The square brackets around optional arguments are not used in the actual call to the function; they are simply used to denote the optional nature of the arguments within this document. Note also that all arguments and keyword arguments to functions should be supplied within the parentheses that follow the function's name.

Arguments

The "Arguments" section describes each valid argument to the routine. Note that these arguments are positional parameters that must be supplied in the order indicated by the method's calling sequence.

Named Variables

Often, arguments that contain values upon return from the function or procedure ("output arguments") are described as accepting "named variables". A named variable is simply a valid IDL variable name. This variable does not need to be defined before being used as an output argument. Note, however that when an argument calls for a named variable, only a named variable can be used—sending an expression causes an error.

Keywords

The "Keywords" section describes each valid keyword argument to the routine. Note that keyword arguments are formal parameters that can be supplied in any order.

Keyword arguments are supplied to IDL methods by including the keyword name followed by an equal sign ("=") and the value to which the keyword should be set. Note that keywords can be abbreviated to their shortest unique length. For example, the XSTYLE keyword can be abbreviated to XST.

Setting Keywords

When the documentation for a keyword says something similar to, "Set this keyword to enable logarithmic plotting," the keyword is simply a switch that turns an option on and off. Usually, setting such keywords equal to 1 causes the option to be turned on. Explicitly setting the keyword to zero (or not including the keyword) turns the option off.

There is a "shortcut" that can be used to set a keyword equal to 1 without the usual syntax (i.e., KEYWORD=1). To "set" a keyword, simply preface it with a slash character ("/"). For example, to plot a wire mesh surface with a skirt around it, set the SKIRT keyword to the SURFACE routine as follows:

SURFACE, DIST(10), /SKIRT

Creating Database Objects

To create a database object, use the OBJ_NEW function (see "OBJ_NEW" in the IDL Reference Guide). The Init method for each class describes the arguments and keywords available when you are creating a new graphics object.

For example, to create a new database object, use the following call to OBJ_NEW:

myDB = OBJ_NEW('IDLdbDatabase')

Destroying Database Objects

To destroy a database object, use the OBJ_DESTROY function (see "OBJ_DESTROY" in the IDL Reference Guide). The Cleanup method is called to perform any class-specific cleanup operations before the object is destroyed.

For example, to remove database object, use the following call to OBJ_DESTROY:

OBJ_DESTORY, myDB


Dialog_DBConnect Function
DIALOG_DBCONNECT()

Use the DIALOG_DBCONNECT function to connect to the DBMS via the standard ODBC dialog boxes. You will be prompted for information required to connect to the desired database. The function returns true (1) unless you selected the dialog's Cancel button, in which case it returns false (0).

Calling Sequence

status = DIALOG_DBCONNECT(DBobj)

Arguments

DBobj

A valid Database object that is not already connected to a data source.

Keywords

DATASOURCE

Set this keyword equal to the name of a data source to which you wish to connect. (If you do not know the data source name in advance, you can use the GETDATASOURCES method of the IDLdbDatabase object to retrieve a list of available data sources.)

Note	Not all drivers support the ability to return a list of available data sources.

USER_ID

Set this keyword equal to the user login name or ID used to log into the datasource.

PASSWORD

Set this keyword equal to the password corresponding to the user ID.

DIALOG_PARENT

Set this keyword to the widget ID of a widget over which the dialog should be positioned.


DB_Exists Function
DB_EXISTS()

Use the DB_EXISTS function to determine if the database functionality is available on a specific platform. DB_EXISTS returns true (1) if the platform in use supports ODBC and the user is licensed to use the IDL DataMiner, or false (0) if it is not available.

Calling Sequence

status = DB_EXISTS()


IDLdbDatabase Object
IDLdbDatabase

An IDLdbDatabase object represents a connection to a datasource. Use the IDLdbDatabase object's instance data and methods to connect to, disconnect from, and perform operations to a Database Management System (DBMS).

Creation

These is no Init method for the IDLdbDatabase object. Use the following IDL command to create a new database object:

DBObj = OBJ_NEW('IDLdbDatabase')

Note that the returned database object is not considered valid until a connection to the datasource is made, either via the IDLdbDatabase::Connect method or the DIALOG_DBCONNECT() function.

Methods

•	IDLdbDatabase::Connect (page 25)

•	IDLdbDatabase::ExecuteSQL (page 26)

•	IDLdbDatabase::GetDatasources (page 27)

•	IDLdbDatabase::GetProperty (page 27)

•	IDLdbDatabase::GetTables (page 29)

•	IDLdbDatabase::SetProperty (page 29)


IDLdbDatabase::Connect

Use the IDLdbDatabase::Connect procedure method to connect to the data source associated with a database object.

Calling Sequence

DBobj ->[IDLdbDatabase::]Connect

Arguments

None

Keywords

CONNECTION

Set this keyword equal to a raw ODBC connection string. No preprocessing is performed on the string before it is passed to the ODBC system. If this keyword is set, all other keywords are ignored.

DATASOURCE

Set this keyword equal to a string containing the name of a datasource to which you wish to connect. This name is dependent on the data source.

USER_ID

Set this keyword equal to a string containing the user login name or ID used to log into the datasource.

PASSWORD

Set this keyword equal to a string containing the password corresponding to the user ID.


IDLdbDatabase::ExecuteSQL

Use the IDLdbDatabase::ExecuteSQL procedure method to execute an SQL statement. No results are expected from this statement; any that are received are discarded. You can use this method to perform actions such as creating or deleting a table. To use this method, the object must already be connected to a datasource.

Calling Sequence

DBobj->ExecuteSQL, strSQL

Arguments

strSQL

A string that contains a valid SQL statement. This statement is executed in the data source referenced by the database object.


IDLdbDatabase::GetDatasources

The IDLdbDatabase::GetDatasources function method returns an array of available datasources. You do not need to make a connection before calling this method.

The GetDatasources method returns an array of IDL structures with the following two fields:

•	DATASOURCE: The name of the database driver

•	DESCRIPTION: A description of the driver.

Calling Sequence

Datasources = DBObj->GetDatasources()

Arguments

None.


IDLdbDatabase::GetProperty

Use the IDLdbDatabase::GetProperty procedure method to retrieve properties of the database object.

Calling Sequence

DBobj->GetProperty

Arguments

None.

Keywords

CAN_GET_TABLES

Set this keyword to a named variable that will contain 1 (one) if the GetTables method is available for the current driver, or 0 (zero) otherwise.

DBMS_NAME

Set this keyword to a named variable that will contain the name of the Database that the object is associated with.

DRIVER_ODBC_LEVEL

Set this keyword to a named variable that will contain the ODBC level supported by the driver being used to connect to the database.

DBMS_VERSION

Set this keyword to a named variable that will contain the version number of the Database that the object is associated with.

DRIVER_VERSION

Set this keyword to a named variable that will contain the version number of the ODBC driver being used to connect to the database.

IS_CONNECTED

Set this keyword to a named variable that will contain 1 (one) if a connection to a database exists, or 0 (zero) otherwise.

IS_READONLY

Set this keyword equal to a named variable that will contain a 1 (one) if the database is read-only, or 0 (zero) if it is writable.

MAX_CONNECTIONS

Set this keyword to a named variable that will contain the maximum number of connections supported by the ODBC driver. If the maximum value is unknown, 0 is returned.

MAX_RECORDSETS

Set this keyword to a named variable that will contain the maximum number of recordsets supported by the ODBC driver. If the maximum is unknown, 0 is returned.

ODBC_LEVEL

Set this keyword to a named variable that will contain the ODBC level of the driver manager.

SQL_LEVEL

Set this keyword to a named variable that will contain the SQL level supported by the connection.

SQL_SERVER_NAME

Set this keyword to a named variable that will contain the SQL server name for this database connection.

USE_CURSOR_LIB

Set this keyword equal to a named variable that will contain 1 (one) if the USE_CURSOR_LIB property was set (via the SetProperty method), or 0 (zero) otherwise. Note that this keyword will return 1 if the USE_CURSOR_LIB property was set, even if the cursor library was not subsequently loaded. See "IDLdbDatabase::SetProperty" on page 29 for details.

USER_NAME

Set this keyword to a named variable that will contain the user name used during the connection to the datasource.


IDLdbDatabase::GetTables

The IDLdbDatabase::GetTables function method returns a list of available tables in the datasource. A connection is required before this method is called. This method is not supported for all drivers.

The GetTables method returns an array of IDL structures with the following fields:

•	QUALIFIER: The table qualifier.

•	OWNER: The owner of the table.

•	NAME: The name of the table

•	TYPE: The type of the table.

Calling Sequence

Tables = DBObj->GetTables()

Arguments

   None.


IDLdbDatabase::SetProperty

Use the IDLdbDatabase::SetProperty procedure method to set properties of the database object.

Calling Sequence

DBobj->SetProperty

Arguments

None.

Keywords

USE_CURSOR_LIB

Set this property to use the ODBC cursor library. The ODBC cursor library is used to emulate advanced functionality on data sources (notably the Microsoft SQL Server) that don't support the advanced functions. Advanced functionality supported by the cursor library includes positioned updates, positioned deletes, and multi-directional cursor movement.

Note	This property must be set (or unset) before the connection to the data source is made. Once the connection is made, this property cannot be changed. The default is to not use the cursor library.

Caution	To support the above-mentioned operations, the cursor library constructs SQL search statements to locate the desired record. If the WHERE clause of the generated SQL statement selects more than one row, the operation will affect more than one record.

VERBOSE

Set this keyword to enable verbose error messages. Normal error messages contain a text explanation (normally from the ODBC system) of the error. Verbose message include the following additional information:

•	The name of the ODBC function that failed,

•	The error code from the ODBC system,

•	The error code from the database.


IDLdbDatabaseRecordset Object
IDLdbRecordset

The IDLdbRecordset object contains a database table or the results from an SQL query.

Creation

To create a recordset object, a valid database object is required. Use the following IDL command to create a new recordset object:

RSObj = OBJ_NEW('IDLdbRecordset', DBobj, KEYWORD)

where DBobj is the object reference of the database object and KEYWORD is one of the following two keywords:

SQL

A string that contains a valid SQL statement that selects records from the database.

TABLE

A string that contains the name of a table in the database. This table must be contained in the database referred to by DBobj.

Methods

•	IDLdbRecordset::AddRecord (page 31)

•	IDLdbRecordset::CurrentRecord (page 32)

•	IDLdbRecordset::DeleteRecord (page 32)

•	IDLdbRecordset::GetField (page 33)

•	IDLdbRecordset::GetProperty (page 33)

•	IDLdbRecordset::MoveCursor (page 35)

•	IDLdbRecordset::NFields (page 36)

•	IDLdbRecordset::SetField (page 36)


IDLdbRecordset::AddRecord

Use the IDLdbRecordset::AddRecord procedure method to add a record to a recordset. If you don't have permission to modify the recordset, an error is returned. The location in the recordset of the new record is dependent on the ODBC Driver, but in most cases it is added to the end of the recordset. This method will fail if the recordset was created via an SQL statement and if the SQL driver doesn't support positioned updates to the recordset.

Calling Sequence

RSObj->AddRecord, [field1][field2]...[fieldn]

Arguments

Any arguments passed to this routine are used to initialize the new record. If these initialization parameters are not provided, the field is initialized to 0.


IDLdbRecordset::CurrentRecord

The IDLdbRecordset::CurrentRecord function method requests the current record number in a recordset. This method is driver-dependent. If the record number of the current record cannot be determined by the ODBC driver, this function returns a negative number.

Calling Sequence

number = RSobj->CurrentRecord()

Arguments

None.


IDLdbRecordset::DeleteRecord

Use the IDLdbRecordset::DeleteRecord procedure method to delete the current record from a recordset. Any attempt to access this record after it has been deleted can result in an error. This method will fail if the recordset was created via an SQL statement and if the SQL driver doesn't support positioned deletions to the recordset.

Calling Sequence

RSobj->DeleteRecord

Arguments

    None


IDLdbRecordset::GetField

Use the IDLdbRecordset::GetField function method to get the value of a field from the current record in the recordset. If the value of the field is NULL (as defined by SQL) an undefined variable is returned.

Calling Sequence

value = RSobj->GetField(iFieldNumber)

 Arguments

iFieldNumber

The number of the field for which the value will be returned. Field numbers have a range of 1 <= n <= number of columns.


IDLdbRecordset::GetProperty

Use the IDLdbRecordset::GetProperty procedure method to get properties of the recordset.

Calling Sequence

RSobj->GetPropertY

Arguments

None.

Keywords

CAN_MOVE_ABSOLUTE

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to an absolute record number.

CAN_MOVE_FIRST

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to the first record.

CAN_MOVE_LAST

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to the last record.

CAN_MOVE_NEXT

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to the next record.

CAN_MOVE_PRIOR

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to the previous record.

CAN_MOVE_RELATIVE

Set this keyword equal to a named variable that will contain 1 (one) if the cursor for the recordset can move to a record number relative to the current record number.

FIELD_INFO

Set this keyword equal to a named variable that will contain an array of field informational structures, one for each column in the result set. These structures have the following fields (see the ODBC Manual for more information):

•	TABLE_QUALIFIER: The table qualifier.

•	TABLE_OWNER: The name of the table owner.

•	TABLE_NAME: The name of the table.

•	COLUMN_NAME: The name of the column.

•	TYPE_NAME: The datasource type name.

•	PRECISION: Precision of the column.

•	LENGTH: Length in bytes of the data.

•	SCALE: The scale of the column.

•	RADIX": The radix of the column.

•	REMARKS: A description of column.

FIELD_TYPES

Set this keyword equal to a named variable that will contain an array of IDL type codes that represent the type of each field.

GET_DATABASE

Set this keyword equal to a named variable that will contain an object reference to the database object used when the current recordset object was created.

IS_READONLY

Set this keyword equal to a named variable that will contain a 1 (one) if the database is read-only, or 0 (zero) if it is writable.

RECORDSET_SOURCE

Set this keyword equal to a named variable that will contain either the table name or SQL statement used to create the recordset.


IDLdbRecordset::IsReadOnly


IDLdbRecordset::MoveCursor

Use the IDLdbRecordset::MoveCursor procedure method to move the cursor in a given recordset.

Calling Sequence

RSObj->MoveCursor

 Arguments

None

 Keywords

ABSOLUTE

Set this keyword to the record number that the cursor should be moved to. Note that the first record is record 1 (one), not record 0 (zero).

FIRST

Set this keyword to move the cursor to the first record in the recordset.

LAST

Set this keyword to move the cursor to the last record in the recordset.

NEXT

Set this keyword to move the cursor to the next record in the recordset.

PRIOR

Set this keyword to move the cursor to the previous record in the recordset.

RELATIVE

Set this keyword to the relative number of records that the cursor should be moved from its current position.


IDLdbRecordset::NFields

The IDLdbRecordset::NFields function method returns the number of fields in the recordset.

Calling Sequence

status = RSobj->NFields()

Arguments

None.


IDLdbRecordset::SetField

Use the IDLdbRecordset::SetField procedure method to set the value of a field in the current record of a recordset.

Calling Sequence

RSobj->SetField, iFieldNumber, Value

Arguments

iFieldNumber

The number of the field whose value is returned. Field numbers have a range of 1 <= n <= number of columns.

Value

The value to which the field should be set. If the provided value is not of the correct type, it is converted.


Topics in the IDL DataMiner Class Specifications Chapter
Topics in the IDL DataMiner Class Specification Chapter

The DataMiner API

DIALOG_DBCONNECT()

DB_EXISTS()

IDLdbDatabase

IDLdbDatabase::Connect

IDLdbDatabase::ExecuteSQL

IDLdbDatabase::GetDatasources

IDLdbDatabase::GetTables

IDLdbDatabase::GetProperty

IDLdbRecordset

IDLdbRecordset::AddRecord

IDLdbRecordset::CurrentRecord

IDLdbRecordset::DeleteRecord

IDLdbRecordset::GetField

IDLdbRecordset::GetProperty

IDLdbRecordset::IsReadOnly

IDLdbRecordset::MoveCursor

IDLdbRecordset::NFields

IDLdbRecordset::SetField


DriverSet Basics

This chapter introduces the Visigenic ODBC DriverSet, describes the API and SQL grammar conformance levels, describes the driver error message format, and provides information about how to access translation libraries with the drivers.


What is the Visigenic ODBC DriverSet
What is the Visigenic ODBC DriverSet?

ODBC stands for Open Database Connectivity, an interface that allows applications to access data in database management systems (DBMSs) using Structured Query Language (SQL) as a standard for accessing data. The ODBC specification defines a vendor-independent API for accessing data stored in relational and non-relational databases. The Core functions and SQL grammar are based on work done by the X/Open SQL Access Group. The ODBC architecture is made up of four components:

•	Database Application. The database application calls functions defined in the ODBC API to access a data source.

•	Driver Manager. The Driver Manager implements the ODBC API and provides information to an application—such as a list of available data sources and drivers— loads drivers dynamically as they are needed, and provides argument and state transition checking.

•	Drivers. Each driver processes ODBC function calls and manages exchanges between an application and a data source.

•	Data Source. A data source contains the data that an application needs to access. The data source includes the data, the database management system (DBMS) in which the data is stored, the platform on which the DBMS resides, and the network (if any) used to access the DBMS.

With the Visigenic DriverSet, the cursor capabilities are implemented using the ODBC Cursor Library. The Cursor Library is a shared library that resides between the Driver Manager and the driver.

An ODBC-compliant driver allows you to communicate between an ODBC-compliant application and a DBMS. For example, the SYBASE SQL Server 10 driver allows you to connect your ODBC-compliant application to a Sybase SQL Server 10 database.

The DriverSet is available on most major platforms. The information in the initialization file that the drivers use, the functions and SQL grammar that the drivers support, and the error message formats are the same across all platforms.

The Visigenic ODBC DriverSet is made up of two ODBC components—the Driver Manager and a set of database drivers. With the ODBC DriverSet, you can access, query, and update data in a number of different databases.


ODBC Conformance Levels

ODBC defines two different conformance standards for drivers—the API conformance standard and the SQL conformance standard. Each conformance standard is made up of three levels. These levels help application and driver developers establish standard sets of functionality.

API Conformance Levels

The API conformance standard is made up of three levels:

•	Core API. A set of core functions that correspond to the functions in the X/Open SQL Access Group Call Level Interface specification.

•	Level 1 API. Core API functionality plus all Level 1 functionality.

•	Level 2 API. Core and Level 1 API functionality plus all Level 2 functionality.

ODBC API Functions

The Visigenic drivers support all Core and Level 1 functions. In addition, each driver supports a key set of the Level 2 functions. For a list of supported Level 2 functions by driver, refer to the appropriate driver chapter's "ODBC Conformance Levels" section.

SQL Conformance Levels

SQL conformance is made up of three levels—Minimum, Core, and Extended. The Minimum level is designed to meet the basic level of ODBC conformance. The Core level roughly corresponds to the X/Open SQL Access Group SQL CAE specification (1995) and the Extended level provides common DBMS extensions to SQL. Most of the Visigenic drivers support all Minimum and Core SQL grammar. In addition, each driver supports a number of extended SQL statements, expressions, and data types. For a list of supported Extended SQL grammar by driver, refer to the appropriate "ODBC Conformance Levels" section in each chapter.

Minimum SQL Grammar

The Minimum level of SQL grammar consists of the following statements, expressions, and data types:

•	Data Definition Language (DDL): CREATE TABLE and DROP TABLE

•	Data Manipulation Language (DML): simple SELECT, INSERT, UPDATE, SEARCHED, and DELETE SEARCHED

•	Expressions: simple (such as A>B+C)

•	Data types: CHAR, VARCHAR, or LONG VARCHAR

Core SQL Grammar

The Core level of SQL grammar consists of the following statements, expressions, and data types:

•	Minimum SQL grammar and data types

•	Data Definition Language (DDL): ALTER TABLE, CREATE INDEX, DROP INDEX, CREATE VIEW, DROP VIEW, GRANT, and REVOKE

•	Data Manipulation Language (DML): full SELECT

•	Expressions: subquery, set functions such as SUM and MIN

•	Data Types: DECIMAL, NUMERIC, SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION

Extended SQL Grammar

The Extended level of SQL grammar consists of the following statements, expressions, and data types:

•	Minimum and Core SQL grammar and data types

•	Data Manipulation Language (DML): outer joins, positioned UPDATE, positioned DELETE, SELECT FOR UPDATE, and unions

•	Expressions: scalar functions such as SUBSTRING, ABS, date, time, and timestamp literals

•	Data types: BIT, TINYINT, BIGINT, BINARY, VARBINARY, LONG VARBINARY, DATE, TIME, TIMESTAMP

•	Batch SQL statements

•	Procedure calls


Accessing Translation Libraries

Drivers are able to call a translation library (for example, a Translation Dynamic Link Library on Windows or a Translation Shared Library on UNIX).

A translation library when the client application and the data source store data in different formats. For example, the application might use a different character set than the data source. The translation library enables a driver to translate all data (such as data values, SQL statements, table names, row counts) that pass between the driver and the data source.

You can specify which translation library to use when you configure a data source. The translation library that you specify must be one that you supply—the Visigenic DriverSet does not provide a translation library.

♦	WINDOWS: For Windows users, the translation library appears as an option at the bottom of the Setup dialog box. The following illustration shows the Setup dialog box for the Ingres driver. This option appears in the same place on every Setup dialog box.

♦	UNIX: For UNIX users, this feature can be used by setting the translation keywords in the .odbc.ini file, for each data source. The translation keywords are as follows:

•	TranslationName. The name of the translation library.

•	TranslationDLL. The path to the translation library.

•	TranslationOption. The option you wish to pass to the translation library. For example, you may enter the code page for a particular character set. The option you enter depends on the translation library you use.

For example, your entry in the .odbc.ini file may look similar to the following:

Example

[ODBC Data Sources]
Agencies=Visigenic Sybase SQL Server

[Default]
Driver=/opt/odbc/drivers/vsorac.so.1
Server=t:mickey:ORASRV
UID=marvin
BufferSize=40000
RowLimit=400
SystemTable=1
CapitalizeCatalogArguments=1
NumberFloatMapping=0
TXN_CAPABLE=0

[Agencies]
Driver=/opt/odbc/drivers/vssyb.so.1
Server=SYBASE10
Database=agencies
UID=marvin
AllowQuotedIdentifiers=1

TranslationName=AcmeGenericCodesetTranslator
TranslationDLL=/opt/odbc/lib/acmetran.so.1
TranslationOption=12344321

♦	Macintosh: On Macintosh, the translation library appears as an option at the bottom of the Setup dialog box.

For a complete description of how to use a translation library, see the "Translating Data" section of chapters 5 and 13 of the ODBC for UNIX Programmer's Reference or the Microsoft ODBC 2.0 Programmer's Reference.


Topics in DriverSet Basics Chapter
Topics in the DriverSet Basics Chapter

What is the Visigenic ODBC DriverSet?

ODBC Conformance Levels

Accessing Translation Libraries


Understanding the ODBC.INI File

The ODBC.INI is an initialization file used by the ODBC Driver Manager and ODBC drivers. Although this file has a slightly different name depending upon what platform you are using, the format and information contained in the file is the same. For any general discussion, the file name appears in uppercase letters.

♦	WINDOWS: For Windows users, ODBC.INI is a text file called ODBC.INI. The file is located in your WINDOWS directory. Although the ODBC.INI file is described in the following sections, Windows users should not modify this file—the ODBC Administrator program modifies it for you. The following sections are intended for informational purposes only.

Caution	Windows users should never modify the ODBC.INI file directly. The contents of this file are changed based on the data source set up and modifications you make using the ODBC Administrator. Modifying the ODBC.INI file directly may result in data source configuration or connection errors.

♦	UNIX: For UNIX users, ODBC.INI is a text file called .odbc.ini. The file is located in your home directory. Initially, a template file called odbc.ini resides in the odbc root directory of the IDL Distribution where the ODBC software was installed. Before using an ODBC driver, each user must copy this file to their home directory and rename it .odbc.ini. (The dot at the beginning of the name follows UNIX conventions for application initialization files.) UNIX users are responsible for modifying their .odbc.ini file using a text editor. For driver-specific .odbc.ini changes and information, refer to the appropriate driver chapter in this manual.


ODBC.INI File Format

The ODBC.INI file is made up of the following sections:

•	ODBC Data Sources. This section lists the name of each data source and describes its associated driver.

•	Data Source Specification. For each data source listed in the ODBC Data Sources section, there is a section that contains additional information about that data source.

•	Default Data Source Specification. This section is optional and specifies the default data source to use when no data source is specified.

•	ODBC Options. This section specifies the ODBC root directory and the ODBC options that may be enabled or disabled.

ODBC Data Sources

Each entry in the ODBC Data Sources section lists a data source and a description of the driver it uses. Entries in this section have the following format:

data_source_name-driver_description

The data_source_name identifies the data source to which the driver connects. You choose this name. This field is required.

The driver_description describes the driver to which the data source connects. This field is optional.

For example, to define an Agencies data source that uses the SYBASE SQL Server 10 driver, the ODBC.INI entry would look like the following:

[ODBC Data Sources]

Agencies=Visigenic Sybase SQL Server 10

Data Source Specification

Each data source listed in the ODBC Data Sources section has its own data source specification section. This section has the following format:

[Data_source_name]

Driver=path_specification

Attribute=keyword_value

The data_source_name is the name defined in the ODBC Data Sources section of the ODBC.INI file.

The path_specification is the full path name to the dynamic link library (Windows), or the full path to the driver shared library (UNIX).

Each Attribute and keyword_value pair specifies the value of a driver-specific keyword. Each driver has its own set of keywords. For driver-specific keywords and attributes, refer to the Visigenic ODBC DriverSet Reference. There can be any number of Attribute/keyword pairs included in the Data Source Specification.

For example, the data source called Agencies connects to a Sybase SQL Server 10 driver for UNIX called vssyb.so.1. The database that Agencies accesses is also called agencies and it resides on the SYBASE10 server. The data source specification entry for the Agencies data source would look like the following:

[Agencies]

Driver=/opt/odbc/drivers/vssyb.so.1

Server=SYBASE10

Database=agencies

UID=marvin

AllowQuotedIdentifiers=1

In this example, the driver-specific keywords for the Sybase driver are Server, Database, UID and AllowQuotedIdentifiers.

Default Data Source Specification

This section is optional. The Default Data Source specification contains information about the default data source. This data source is called Default and has the same format as any other data source specification section. However, the Default data source is not listed in the ODBC Data Sources section.

The following example shows a Default data source specification entry for an Oracle7 database.

[Default]
Driver=/opt/odbc/drivers/vsorac.so.1
Server=t:mickey:customers
UID=marvin

In this example, the driver-specific keywords for the Oracle7 driver are Server and UID. The Server keyword identifies the SQL*Net connect string for the ORACLE7 server called customers.

ODBC Options

The ODBC Options section specifies the ODBC root directory (UNIX only) and indicates whether tracing is enabled or disabled. With tracing, all ODBC function calls made from an application can be logged to the specified trace file.

Caution	For UNIX users: This section of the .odbc.ini file is recommended for UNIX installations so that the Driver Manager can find the message files. The Driver Manager also uses this section to load the Cursor Library and the Connection Dialog Library. At a minimum, the [ODBC] section must contain the InstallDir keyword with the value set to the path in which the DriverSet is installed.

This section has the following format:

InstallDir=odbc_path

Trace= 1 or 0

TraceFile=log_path

TraceAutoStop= 1 or 0

The odbc_path is the full path to the ODBC root directory. This option appears only in the UNIX version of the ODBC.INI file.

If the Trace keyword is set to 0, tracing is disabled. If the Trace keyword is set to 1, tracing is enabled.

The log_path is the full path to the specified trace file that is logging the ODBC function calls. If a trace file is not specified and tracing is enabled, logging information is written to the sql.log file located in your current directory.

The TraceAutoStop keyword indicates whether tracing is enabled or disabled when an application calls the SQLFreeEnv() function. If the TraceAutoStop keyword is set to 0, tracing is not automatically disabled. If the TraceAutoStop keyword is set to 1, the Trace keyword in the ODBC.INI file is set to 0. Additionally, on Windows all other concurrent ODBC applications will have tracing disabled.

The following is an example entry for the [ODBC] section:

[ODBC]
InstallDir=/opt/odbc
Trace=1
TraceFile=/opt/odbc/drivers/trace.log
TraceAutoStop=0

♦	UNIX: Message files (odbc.m, odbccurs.m, and vsdrvmsg.m) are stored in the <InstallDir>/messages/default directory where InstallDir is an entry in the [ODBC] section of the .odbc.ini file. At a minimum, the [ODBC] section must contain the InstallDir keyword with the value set to the path in which the ODBC SDK or DriverSet is installed, as shown in the following example.

InstallDir=/opt/odbc

If the [ODBC] section is not available, the Driver Manager will default to /opt/odbc for Solaris 2.x and above. Refer to the Visigenic ODBC DriverSet Release Notes for information about all other platforms.


ODBC.INI File Examples

♦	WINDOWS: The following example shows a Windows ODBC.INI file.

[ODBC Data Sources]
Contacts=Visigenic Oracle7 Driver
Sales=Visigenic Ingres 6.4 Driver
Stores=Visigenic Informix 5 Driver

[Default]
Driver=C:\WINDOWS\SYSTEM\VSINGR64.DLL
ServerName=odin
Database=vendors
UID=mary

[Contacts]
Driver=C:\WINDOWS\SYSTEM\VSORAC.DLL
Server=t:odin:ORA7
UID=mary
BufferSize=40000
RowLimit=400
SystemTable=1
CapitalizeCatalogArguments=1
NumberFloatMapping=0
TXN_CAPABLE=0

[Sales]
Driver=C:\WINDOWS\SYSTEM\VSINGR64.DLL
ServerName=mickey
Database=Sales
UID=mary

[Stores]
Driver=C:\WINDOWS\SYSTEM\VSIFMX5.DLL
Database=Stores
UID=mary
NoHoldCursors=1
TrueCharPrecision=1
TxnDMLOnly=1

[ODBC]
Trace=1
TraceFile=C:\WINDOWS\LOG\TRACE.LOG
TraceAutoStop=0

♦	UNIX: The following example shows a UNIX .odbc.ini file.

[ODBC Data Sources]
Agencies=Visigenic Sybase SQL Server
Stores=Visigenic Informix 7 Driver

[Default]
Driver=/opt/odbc/drivers/vsorac.so.1
Server=t:mickey:ORASRV
UID=marvin
BufferSize=40000
RowLimit=400
SystemTable=1
CapitalizeCatalogArguments=1
NumberFloatMapping=0
TXN_CAPABLE=0

[Agencies]
Driver=/opt/odbc/drivers/vssyb.so.1
Server=SYBASE10
Database=agencies
UID=marvin
AllowQuotedIdentifiers=1

[Stores]
Driver=/opt/odbc/drivers/vsifmx7.so.1
Database=stores
UID=marvin
NoHoldCursors=1
TrueCharPrecision=1
TxnDMLOnly=1

[ODBC]
InstallDir=/opt/odbc
Trace=1
TraceFile=/opt/odbc/drivers/trace.log
TraceAutoStop=0


Topics in Understanding the ODBC.INI file
Topics in the ODBC.INIs Chapter

ODBC.INI File Format

ODBC.INI File Examples