This file describes the Easysoft ODBC-ODBC Bridge (OOB) specific
attributes and how they are used.

You may pass any of the following attributes to the OOB or specify
them in your odbc.ini file:

DSN
---

The data source name. This should already have been defined in your
ini file (for non-Windows platforms) or the registry (via the ODBC
Administrator in Windows). Any attributes the OOB requires but which
are not specified in the connection string are pulled from the named
data source definition.

DRIVER
------

The Driver attribute points the driver manager at the ODBC driver to
use. It can be used for DSN-less connections.

In Windows the Driver attribute points to the DLL which is the ODBC
driver to be used for the connection.

In UNIX the Driver attribute points to an entry in the odbcinst.ini
file which defines the installed drivers. For unixODBC, you must
include the DRIVER attribute in data sources defined in your odbc.ini
files or pass DRIVER=xxx in the connection string.

TARGETDSN
---------

The name of a datasource on the remote machine. You should set this up
with the Windows ODBC Administrator or define it in the odbc.ini file
used by the remote driver manager. This MUST be a SYSTEM datasource as
the OOB server can only see SYSTEM data sources in Windows.

SERVERPORT
----------

The fully qualified domain name (or IP address) of the machine where
the remote data source is located (and where the OOB Server process is
installed), a colon then the port on which the server is
listening. e.g. myserver:8888. You may separate multiple server
definitions with commas in which case if the Client cannot connect to
the first server it will attempt to connect to the next and subsequent
server.

Note: THE PORT IS NOT THE PORT SQLSERVER OR ANY OTHER DBMS IS LISTENING ON.

LOGONUSER
---------

This is the username used to log in to the remote machine (SERVER).
The OOB server will check the LOGONUSER user exists and their password
is LOGONAUTH. If this is successful then the server process will
change to become the specified user.

Whether or not you username and password are case-sensitive is up to
the operating system the OOB Server is running on.

LOGONAUTH
---------

See LOGONUSER above.
This is the password of the LOGONUSER on the machine SERVER.

TARGETUSER
----------

The TARGETUSER (if specified) is passed to the server as the ODBC UID
connection attribute used by ODBC drivers to restrict access to a set
of database users. This is NOT necessarily the name of a user who
exists as far as the operating system is concerned.

TARGETAUTH
----------

See TARGETUSER above.
This is passed to the server as the ODBC PWD connection attribute.

BlockFetchSize = n
------------------

0 <= n <= 100
Default: n=0

When set to a number greater than 0 this causes the OOB to use an
optimisation to retrieve rows from a result-set alot faster. This will
only work if you are not binding columns yourself and cannot be used
if you are going to perform positioned updates or deletes.

DisguiseWide = n
----------------

n = 0 (disabled), n = 1 (enabled)

This is a workaround for ODBC applications that do not recognise the
wide column types SQL_WCHAR, SQL_WVARCHAR and SQL_WLONGVARCHAR
(e.g. StarOffice and Microsoft Query X on MAC OS X). When set to 1 it
converts these types to the normal SQL_CHAR, SQL_VARCHAR and
SQL_LONGVARCHAR. 

In StarOffice 5.1 and 5.2beta this must be set if you are going to MS
SQLServer or you will not see any tables. 

In Microsoft Query X this must be set if you are going to MS SQLServer
or you will not see any tables, all the table names will be blank.

This is currently not available in the Windows dialogue for OOB.

MetaDataBlockFetch = n
----------------------

n = 0 (disabled) n = 1 (enabled)

By default OOB uses the above blockfetchmode automatically to retrieve
result sets generated by metadata functions. You can turn this off
(say if your ODBC driver does not support SQL_ATTR_ROW_ARRAY_SIZE) by
setting MetaDatBlockFetch to 1. A common symptom of an ODBC driver not
working correctly with metadatablockfetch is when you only see the
first 2 rows in a result set and possibly after that ever 10th row.

UseOOBDBAuth = n
----------------

n = 0 (disabled) n = 1 (enabled)

By default OOB uses the UID/PWD in the connection string (or the
username/authentication parameters in the call to SQLConnect) in
preference to the TargetUser/TargetAuth in the DSN (ini/registry) when
connecting to the ODBC driver. This is the logical thing to do as the
UID/PWD is often prompted for by the application connecting to the OOB
client.

If you set UseOOBDbAuth then the OOB will ignore the UID/PWD and use
TargetUser/TargetAuth (if they exist) in preference for the database
login. This flag was introduced for a problem using Crytal Reports
through OOB to Zortec/Tetra.

Unquote_Catalog_Fns
-------------------

n=0 (disabled) n = 1 (enabled)

Unquote_Catalog_Fns removes the double quotes from around names in the
calls to catalog functions such as SQLColumns. This gets around a
problem in Applixware (reported 16th March 1999 and assigned incident
number 4469466) where it can incorrectly quote arguments to the
catalog functions.

The default is 0.

Set to 1 to remove double-quotes from around arguments to catalog
functions.

MetaData_ID_Identifier
----------------------

n=0 (disabled) n = 1 (enabled)

MetaData_ID_Identfier causes the OOB client to call SQLSetStmtAttr
with the SQL_ATTR_METADATA_ID attribute to set it to SQL_TRUE. This
causes ODBC 3.0 drivers to treat strings in metadata functions as
literals. This attribute is useful if you have an application you
cannot change which assumes all strings in metadata calls are treated
as literal but are going to an ODBC driver containing tables etc with
special characters in them (e.g. _).  Applixware's AXData sometimes
needs this attribute defining.

The default is 0.

Set to 1 to cause the OOB Client to set SQL_ATTR_METADATA_ID to
SQL_TRUE meaning strings are treated as literals.

MapExecDirect
-------------

n=0 (disabled) n=1 (enabled)

MapExecDirect is a switch telling OOB whether to map calls to
SQLExecDirect to SQLPrepare/SQLExecute for ODBC 2.0 applications.

Between ODBC 2.0 and 3.0 a change in the allowable state transitions
occurred. In ODBC 2.0 an app could call SQLDescribeParam even in the
executed state (i.e. after the call to SQLPrepare AND after the call
to SQLExecute). In ODBC 3.0, this is no longer possible. OOB works
around this limitation for ODBC 2.0 apps by mapping SQLExecDirect to
SQLPrepare/SQLExecute and caching the parameter descriptions in
between).

OOB has always performed this mapping for ODBC 2.0 applications but
MapExecDirect allows you to turn it off.

The default is 1.

GetInfoPassThru
---------------

n=0 (disabled) n=1 (enabled)

Pass all SQLGetInfo requests through.

When enabled this option to causes SQLGetInfo requests for the ODBC
driver name, version and ODBC version to be sent to the remote ODBC
driver instead of returning the OOB Client name and version. This may
be useful in situations when you want to know the remote ODBC driver
so the application can take alternative actions.

The default is 0.

OverrideLength
--------------

n=0 (disabled) n=1 (enabled)

In calls to SQLGetInfo, SQLGetConnectAttr, SQLGetStmtAttr and
SQLGetDescField the OOB Client normally passes the BufferLength
argument as specified by the application over to the OOB Server and
hence the remote ODBC Driver. For integer attributes the ODBC
specification says that a driver should ignore the BufferLength
argument when the attribute is an ODBC defined one.

We have come across an ODBC driver which does not follow the ODBC
specification. If you pass a BufferLength smaller than the size of an
SQLINTEGER/SQLSMALLINT to SQLGetInfo it returns SQL_SUCCESS_WITH_INFO,
01004, data truncated, and does not return the attribute
value. Setting OverrideLength to 1 causes the OOB Client to override
the application specified BufferLength with either the size of an
SQLINTEGER or SQLSMALLINT which works around the problem with the
ODBC driver.

The default is 0.

IgnoreStmtAttr
--------------

A comma separated list of statement attributes which the OOB Client
will block (returning SQL_SUCCESS) from getting to the back end ODBC
driver.

e.g.
IgnoreStmtAttrs = 1,10014
to block SQL_ATTR_MAX_ROWS and SQL_ATTR_METADATA_ID

The default is to not block any attributes.