|
|
|
A data source configuration is a collection of information that identifies the database you want to access using the ODBC driver. You can configure as many data sources as you require. Once defined, a data source is available for use by any application that uses ODBC.
ODBC data sources are a convenient way of connecting to a database. You can, however, connect to a database without them by using only a connection string. For details, see Connection String Keywords.
To configure a new data source on Windows
You can define one or more data sources for each installed driver. The data source name must provide a unique description of the data; for example, Payroll or Accounts Payable.
A data source can be defined as system or user, depending on whether it must be visible to all users (and services) or only the current user.
Note: A system DSN pointing to a public server definition is required for Microsoft Internet Information Server (IIS) and Microsoft Transaction Server (MTS).
The Create New Data Source dialog opens, which lists all the ODBC drivers installed on your system.
Note: To switch ODBC DSNs defined previously for the ODBC 2.8 driver to the new ODBC 3.5 driver, remove the DSN by selecting it in the ODBC Data Source Administrator Data Sources list, and clicking Remove. Add the DSN again using the new ODBC driver.
The Ingres ODBC Administrator dialog opens.
The Test button is activated.
You should receive a Successful Connection message.
The data source is created. You are returned to the ODBC Data Source Administrator, where your newly defined data source appears in the Data Sources list.
|
|
|
The Data Source tab of the Ingres ODBC Administrator has the following options:
Defines the data source name (DSN) by which an ODBC application connects to a database server.
Limits: A character string of up to 32 characters, which can included any combination of letters, numbers, spaces, or special characters.
Examples: Accounting or INGRES-Serv1
Is an optional long description for a data source name.
Examples: My Accounting Database or INGRES on Server number 1
Specifies the name of the virtual node that has been defined for the local instance to identify a particular remote database server instance. Choose LOCAL if the database resides on the local node.
Specifies the class of database server being accessed. The default is INGRES, which indicates an Ingres DBMS Server. If the database server installation is being accessed through an Enterprise Access server, specify the gateway server class (for example, IDMS).
Identifies the name of the database that the application accesses by default.
Prompts for the UID and PWD information when the connection is being established, if these arguments are not passed in the function call.
An ODBC application connects to a data source using the Open method, SQLConnect, or SQLDriverConnect function call. Optional parameters are user ID (UID) and password (PWD) arguments. In ADO, they are specified as part of the connection string.
The application must be sensitive to Windows for the prompt to appear. If this option is not checked, the user is not prompted (unless the data source name (DSN) is also needed) and only the login information in the VNODE definition is used.
Allows the passing of Enterprise Access specific parameters to certain subsequent statements in a given connection. When specifying options, do not include the "WITH" keyword, and separate multiple options with a comma, (that is, keyword=value,keyword=value).
Example:
dcom_ct_option = `in area CASQLDEFAULT`
Identifies a role ID and its associated password if a role identifier has been defined that associates privileges with the role.
Identifies a group identifier for the session. This identifier is equivalent to the -G flag of the Ingres command-line flags.
Tells the Ingres ODBC driver to reject all attempts to perform database updates for the target database.
Tests the current settings for the data source name to insure that a proper connection can be made through the ODBC. The Test button also refreshes (or creates if it does not exist already) a cache kept in the DSN definition for improved performance by the ODBC driver when accessing EDBC or Enterprise Access gateways. The cache contains the capabilities of the server for identifier name case, name lengths, DBMS release, and so on.
The cache is populated during creation or modification of the DSN definition during the database dropdown and changes applied. The driver at application runtime uses the cache from the DSN if the servername and servertype in the DSN is not overridden by the servername and servertype in the application's connection string (if present).
Using the DSN cache improves connection performance to DB2, VSAM, IMS, IDMS, DCOM (and so on) by eliminating the round-trips to the server caused by the capabilities queries during the ODBC connection process.
|
|
|
The Advanced tab of the Ingres ODBC Administrator has the following options:
Causes select loops rather than cursors to be used. A SELECT query generated through SQLExec, ExecDirect, or the Execute method creates result sets. If multiple rows are to be fetched, the result set is traversed using a select loop or cursor loop.
Select loops generally have the best performance, especially for fetching a large number of rows. However, only one select loop can be active at a time. Select loops are not nested.
For example, in ADO, multiple record set objects cannot be retrieved within [Connection].BeginTrans and [Connection].CommitTrans methods. In direct ODBC code, SQLFreeStmt must be called before executing another select loop.
Causes cursors rather than select loops to be used. Cursors can be slower than select loops, but cursors place no limits on the number of active result sets. Cursor loops can be nested.
Cursor loops offer better performance for MS Access, ADO, and OLE DB applications because fewer ODBC connections are created. This is because the ODBC driver returns information that it supports unlimited active statements when the "cursor loop" option is selected. ADO and OLE DB respond to this information by reusing existing connections for internal cursor engine and meta data functions instead of creating new connections.
If the ODBC application is written directly (without using a higher-level interface such as ADO), and a statement handle has set an explicit cursor name using SQLSetCursorName(hstmt), a cursor loop is always used for that particular result set associated with the statement handle, regardless of the setting in the configuration dialog.
Causes the ODBC driver to convert the ownername.tablename.columnname references to tablename.columnname references. Some applications, such as Microsoft Visual Interdev fully qualify their column-name references as ownername.tablename.columnname references. Older Ingres 6.4 based servers and gateways cannot handle this form of the SQL syntax.
Includes "SYS*" tables in the result set. By default, the ODBC driver filters out tables beginning with "SYS*" when the SQLTables() query is executed, as these are usually system (internal) tables.
Causes applications to receive a more meaningful NULL value when displaying an empty string date, which is preferred by some applications, such as MS Access and MS Excel. By default, the ODBC driver returns the date value of 9999-12-31 23:59:59 for empty date values.
Causes applications to receive a NULL value when fetching the "magic" date of 1582-01-01. Some MK (Manufacturing Knowledge) applications load their database with this date to indicate a default beginning date. This is meaningless, however, to other applications that use the same date.
Causes the ODBC driver to use two sessions with a separate session for ODBC catalog functions (SQLTables, SQLColumns, SQLPrimaryKeys, and so on). This behavior is used by older releases of the ODBC driver. By default, the ODBC driver uses just one database session for all ODBC functions. This option is only needed for compatibility issues where Select Loops were used and the application was relying on the separation of interleaved main and catalog function result sets. Before using this option, first try selecting the Cursor Loops option to solve any compatibility issues.
Causes the ODBC driver to ignore a numeric overflow, underflow (and so on) condition. By default, this condition is an error. This option is equivalent to the –numeric_overflow=ignore command line flag.
Causes ODBC applications to evaluate the II_DECIMAL variable and use a comma if so specified. If this box is not checked, or II_DECIMAL is not defined as a comma character (","), the ODBC defaults to a period character (".").
Tells the ODBC driver to allow applications to execute database procedures that perform updates. If the box is not checked, the default behavior is to reject execution of updating database procedures. This applies only to Ingres II databases and all later releases.
Causes the driver to return NULL for schema (owner) names for the ODBC catalog functions. The option is not safe if a user has table t1 and the DBA also has a table t1 in the database. There is no problem if user1 has a table t1 and user2 also has a table t1. Table names returned are limited to those owned by the current user or DBA. This avoids problems between user1 and user2, but not with the DBA. Although SQLTables work, ambiguities between user and DBA duplicate table names cause failures on calls to SQLColumns, SQLPrimaryKeys, SQLSpecialColumns, etc. when this option is selected This option must be used with caution.
Tells ODBC catalog functions to not treat underscore characters as wildcards.
Displays the specified character for each character that fails to convert from Unicode. For instance, if the character X is specified, the string "mulitbXXX" means that the string had three Unicode characters that could not be displayed in the current codepage.
This field is for applications that display Unicode data as multi-byte.