ODBC Tracing on All Platforms--Internal ODBC Tracing
Internal ODBC tracing is available on all platforms, regardless of the ODBC application used. Internal ODBC tracing follows the conventions of GCA and API tracing and relies on specification of Actian X environment variables to generate the trace.
The environment variable II_ODBC_LOG specifies the file name of the ODBC trace. We recommend specifying the full path of the trace log file; otherwise it may be difficult to find the log after the application is executed.
To prevent the server from writing to the wrong log, the file name can contain one or both of the following parameter values:
%p – Replaced at startup with the Process Identifier (PID) of the server process.
%d – Replaced at startup with the current date in YYYYMMDD format.
For example:
II_ODBC_LOG = $II_SYSTEM/ingres/files/odbctrace_%d_%p.log
The environment variable II_ODBC_TRACE specifies the tracing level, which ranges from 0 to 5. (The higher the value, the more detailed the output.)
The ingsetenv utility can be used to specify ODBC tracing. In IIS environments, this utility is the only option.
Note: Use ingsetenv carefully, since all ODBC applications will “see” these variables whenever they are executed.
Example: ODBC Tracing Using ingsetenv
ingsetenv II_ODBC_LOG C:\temp\odbc.log
ingsetenv II_ODBC_TRACE 5
If possible, it is preferable to use platform-specific commands to set the trace variables, especially if your environment executes many ODBC applications simultaneously.
On Windows, ODBC tracing is specified as follows:
> set II_ODBC_TRACE=5
> set II_ODBC_LOG="C:\My Path\odbctrace.log"
On Linux, ODBC tracing is specified as follows:
# II_ODBC_TRACE=5
# export II_ODBC_TRACE
# II_ODBC_LOG=/tmp/odbctrace.log
# export II_ODBC_LOG
You may wish to add GCA or API tracing. The environment variables II_GCA_TRACE and II_API_TRACE can be used in addition to II_ODBC_LOG.
Here is a sample excerpt from an ODBC trace log that specifies both ODBC and GCA tracing:
!ODBC Trace: SQLGetInfo (ca7cd0, 77, 21f0a4, 100, 21f144)
!ODBC Trace: ResetDbc
!ODBC Trace: SQLDriverConnect ()
!ODBC Trace: ResetDbc
!ODBC Trace: ConDriverName
!ODBC Trace: ConDriverInfo
!ODBC Trace: SQLConnect (ca7cd0, 0, 0, 0, 0, 0, 0)
! 0 GCA_REQUEST timeout=120000 async
! 0 GCA SA_INIT status 00000000 (0)
! 0 GCA SA_JUMP status 00000000 (1)
! 0 GCA RQ_INIT status 00000000 (222)
! 0 GCA_REQUEST target='var/INGRES' prot=66
! 0 GCA RQ_ALLOC status 00000000 (223)
! 0 GCA SA_BUFFERS status 00000000 (224)
! 0 GCA RQ_IS_NOXLATE status 00000000 (225)
! 0 GCA RQ_IS_RSLVD status 00000000 (226)
! 0 GCA RQ_ADDR_NSID status 00000000 (227)
! 0 GCA RQ_IS_NMSVR status 00000000 (228)
! 0 GCA RQ_USE_NMSVR status 00000000 (229)
Note: Do not define II_API_LOG or II_GCA_LOG if you want to include ODBC trace information. II_ODBC_LOG must be defined.
Internal versus Standard ODBC Trace Logs
Internal ODBC trace logs are most useful for ODBC problems that are not related to the ODBC, such as:
• Problems connecting to the database
• Errors reported from the DBMS server, such as SQL syntax errors, table permission errors, or failure to return data from a query
• Errors related to commit or rollback
On Windows, internal ODBC trace logs is the only option for ODBC applications executed from IIS.
Standard ODBC trace logs are best for general use. Sometimes the best results are obtained by generating both types of trace logs.