ADVANCED OPTIONS
StarWare StarSQL 1.04
September 19, 1995
Copyright 1995, StarWare Connectivity Software, Inc

The following keywords can be added to any StarSQL data source in the 
C:\WINDOWS\ODBC.INI file. Specify these keywords only in the ODBC.INI 
data source; they are ignored if passed to StarSQL in a connection 
string unless otherwise noted.

For WindowsNT and Windows 95, use the Registry Editor to modify ODBC.INI - 
Hkey_Current_User
	Software
		ODBC
			ODBC.INI

CreateTable:

This keyword allows you to specify additional text to be appended to 
CREATE TABLE statements - that is, add the following line in ODBC.INI 
for each StarSQL data source used for exporting tables to DB2:

	CreateTable=IN DATABASE database-name

If StarSQL finds this keyword, then the driver appends the string value 
set for the keyword to the CREATE TABLE statement. For example, if the 
data source contains the line,

	CreateTable=IN DATABASE DSNTEST

and the statement being scanned is,

	CREATE TABLE MYTABLE (DEPT INTEGER)

then StarSQL appends the string as follows:

	CREATE TABLE MYTABLE (DEPT INTEGER) IN DATABASE DSNTEST

This allows applications such as Microsoft Query and Microsoft Access to 
export tables to DB2. These applications encounter problems with DB2 
because they issue statements such as:

	CREATE TABLE MYTABLE (DEPT INTEGER)

which DB2 interprets as:

	CREATE TABLE MYTABLE (DEPT INTEGER) IN DATABASE DSNDB04

and the user may not have authorization to the database DSNDB04.

The CreateTable keyword is only enabled when scanning is enabled on the 
ODBC statement handle (default).

Warning: Using both a modified data source (with the CreateTable 
keyword) and a modified SQL command (that is, appending text to a 
"CREATE TABLE" SQL command) could result in a syntax error.


SpecialColumns:

For performance reasons, the default behavior of the SQLSpecialColumns 
catalog function is to return an empty result set. You can enable 
SpecialColumns by specifying "SpecialColumns=ON" in the ODBC.INI file.

For DB2, we recommend that you enable SpecialColumns when you use 
StarSQL with query tools, like MS-Query, that use SQLSpecialColumns to 
determine the optimal set of columns for a searched update. Otherwise, 
if the target table has floating point fields, searched updates may fail 
due to a potential loss of precision when converting from local floating 
point representation.

Note: This recommendation prevents only the failure of a searched update 
if the target table has a unique index that does not include columns of 
the following types: FLOAT, REAL, or DOUBLE PRECISION.


BinaryCCSID:

This keyword specifies how StarSQL interprets data it receives that has 
a CCSID of 65535 (0xFFFF). CCSID 65535 usually means "this is binary 
data, not character data." Use this keyword to choose whether StarSQL 
interprets CCSID 65535 data as binary or character data.

The default behavior of StarSQL is to interpret CCSID 65535 as binary 
data (CCSID 65535) for DB2 and as character data (CCSID 500, or 
StarSQL's active CCSID as described in the "AutoTypDefOvr & TypDefOvr" 
section below) for AS/400. To change the behavior for a particular data 
source, add the keyword "BinaryCCSID = nnn" to that data source, where 
nnn is either 0 (to interpret as binary data) or a CCSID of your choice.

The default shipped value of the AS/400 system value, QCCSID, is 65535. 
We recommend that you change the system value from this default using 
the command "WRKSYSVAL QCCSID". IBM recommends a value of 37 for USA, 
Canada, Netherlands, Portugal, Brazil, Australia, and New Zealand. See 
Chapter 5 "International Considerations" of the StarSQL User's Guide for 
details and recommendations for other countries.

If changing the system value is not possible, you can change the CCSID 
field of the user profile of all users who will be using StarSQL. Use 
the WRKURSPRF command and function key F21 to select "Intermediate 
Options."

However, the new value only affects new SQL collections and tables 
created under the new QCCSID; existing SQL collections and tables still 
report their CCSID as 65535 (for SQL collections, the affected fields 
are the columns of the SQL catalog tables themselves). The keyword 
BinaryCCSID gives to the StarSQL user the flexibility to specify how 
CCSID 65535 should be interpreted.

Beginning with v1.0.2, StarSQL supports connecting to an AS/400 with 
QCCSID 65535 (i.e. *HEX, or 0xFFFF) without adding special flags in the 
data source. The editing of the data source is now needed if the AS/400 
system or user CCSID is not 65535 and you wish to interpret a field with 
QCCSID 65535 as binary data.

You can also use the BinaryCCSID keyword in ODBC.INI to interpret fields 
with CCSID 65535 as character data of a CCSID of your choice. For 
example:
	BinaryCCSID=37
This keyword is also supported on the SQLDriverConnect szConnStrIn 
string. For example:
	"DSN=DSName;UID=UserID;BinaryCCSID=37"

This setting affects the following:

1. At the initial connection, when the AS/400 reports that it will be 
using CCSID 65535 (0xFFFF), StarSQL pretends that the BinaryCCSID 
setting was sent instead. Auto-matching with the AutoTypDefOvr ODBC.INI 
keyword works as if the AS/400 sent the configured CCSID value. 

2. When binary fields are sent to StarSQL from the AS/400, they are 
treated as if they were character strings in the CCSID of the 
BinaryCCSID setting. 

If you put the wrong value in BinaryCCSID, some things do not work. For 
example, if your AS/400 is using CCSID 37, but QCCSID is set to 65535 
and you by mistake configure BinaryCCSID=819, an SQLPrepare would fail 
with the message, "[StarWare][StarSQL ODBC Driver][DB2/400]Function 
check." 

AutoTypDefOvr & TypDefOvr (SWODBC.INI & ODBC.INI):

When a StarSQL data source connects to the host, the host reports the 
CCSID that it will use, and StarSQL automatically matches the CCSID 
chosen by the host. These keywords allow you control over the selection 
of the CCSID.

As shipped, SWODBC.INI contains:

[Defaults]
AutoTypDefOvr = 500,0,0
(CCSIDs for single byte, multi byte, and double byte)

When StarSQL first connects, it tries to send CCSID=500 to the host. If 
the host sends something else back, StarSQL uses that CCSID for the rest 
of the session and adds the following statement to the data source in 
ODBC.INI:

AutoTypDefOvr = nnn,nnn,nnn
(where nnn is the host's CCSID).

The next time StarSQL uses the data source, 'nnn' is used for the 
initial connection. If the host's CCSID has changed, the data source is 
changed again in preparation for the next connect.

If you know the host's CCSID, you can enter these keywords in advance to 
send that CCSID in the initial connect. Modify the keyword in SWODBC.INI 
to change the behavior for all data sources or add the keyword in 
ODBC.INI to change the behavior for a specific data source.

TypDefOvr = nnn,nnn,nnn

If StarSQL finds the keyword "TypDefOvr" in a data source in ODBC.INI, 
then it uses that CCSID when connecting to the host and continues to use 
that CCSID throughout the session regardless of the host's CCSID. This 
overrides any values specified by the AutoTypDefOvr keyword.

IsolationLevel = n

This release of StarSQL lets the user override the default transaction 
isolation level on a per Data Source basis.

Adding an entry for IsolationLevel to the data source description in the 
ODBC.INI file (registry database for Windows NT) changes StarSQL's 
default transaction isolation level from SQL_TXN_READ_COMMITED to the 
specified value.  Values are specified as decimal numbers.

Example : IsolationLevel=4

Possible values are:
NONE=0 (AS/400 v2r3 & later only)
SQL_TXN_READ_UNCOMMITTED=1
SQL_TXN_READ_COMMITED=2
SQL_TXN_REPEATABLE_READ=4
SQL_TXN_SERIALIZABLE=8

The isolation level SQL_TXN_VERSIONING is not supported by the databases 
accessible through StarSQL.

If an application explicitly specifies a desired transaction isolation 
level, that setting is used in place of the IsolationLevel option 
specified in the data source specification of the ODBC.INI file. The 
IsolationLevel parameter cannot be passed to the driver in the 
SQLDriverConnect call.

AS/400 v2r3 and later only - Setting IsolationLevel=0 allows the StarSQL 
driver to access non-journaled physical files on the AS/400 by using 
commitment control *NONE.

GUPTA1: 
For Gupta SQLWindows or QuestReporter pre-v.5.0.2: You must edit ODBC.INI and 
add the following flag to the datasource:

	Gupta1=1

If you will be using Gupta SQLWindows or QuestReporter v5.0.2, you are 
no longer required to add the Gupta1=1 flag to the ODBC.INI file. If you 
have used Gupta pre-v.5.0.2 and have added this flag, remove it before 
you use StarSQL with Gupta or QuestReporter v5.0.2 and later. 

RmtTPName (for connecting to SQL/DS):
An additional configuration step is required when connecting to SQL/DS 
3.4: the remote transaction program name of the SQL/DS DRDA Application 
server has to be added to the data source definition in either ODBC.INI 
for the 16-bit driver or in the registry for the 32-bit driver. The 
keyname is RmtTPName. Example: 

	RmtTPName=SYSDBA