DEFAULTS: Press to this
button restore the normal defaults for the settings described below.
Disable Genetic Optimizer: Automatically
turns off the backend genetic optimizer at connection time. This
is a convenience feature rather than having to type it in the connect settings.
This feature was added when we noticed the backend seemed to have
big problems optimizing some queries.
CommLog (C:\psqlodbc.log):
Log communications to/from the backend to that file. This is good
for debugging problems.
Recognize Unique Indexes:
This controls what SQLStatistics() will return about unique indexes.
By default it is set to false. This setting allows Access 95 and
97 to ask the user at link time what the index should be. This is
meant as a workaround until the backend canonifier can handle the Microsoft
Access queries better. For some applications (i.e., Access 2.0), you must
set this option to update any tables.
ReadOnly (default): New
datasources will inherit the state of this box for the datasource readonly
attribute.
Use Declare/Fetch: If
true (default), the driver automatically uses declare cursor/fetch to handle
SELECT statements and keeps 100 rows in a cache. This is mostly a
great advantage, especially if you are only interested in reading and not
updating. It results in the driver not sucking down lots of memory
to buffer the entire result set. If set to false, cursors will not
be used and the driver will retrieve the entire result set. For very
large tables, this is very inefficient and may use up all the Windows memory/resources.
However, it may handle "updates" better since the tables are not kept open,
as they are when using cursors. This was the style of the old podbc32
driver. However, the behavior of the memory allocation is much improved
so even when not using cursors, performance should at least be better than
the old podbc32.
Parse Statements: If enabled,
the driver will parse an SQL query statement to identify the columns and
tables and gather statistics about them such as precision, nullability,
aliases, etc. It then reports this information in SQLDescribeCol,
SQLColAttributes, and SQLNumResultCols. Borland especially relies
on these statistics and since the Postgres backend does not report this
information in a query result, the parsing option is the only accurate
way of getting it. If the parser can not deal with a column (because
it is a function or expression, etc.), it will fallback to executing the
statement which is the old style of getting the info. The parser
is fairly sophisticated and can handle many things such as column and table
aliases, quoted identifiers, literals, joins, cross-products, etc.
It can correctly identify a function or expression column, regardless of
the complexity, but it does not attempt to determine the data type or precision
of these columns.
Unknown Sizes: This controls
what SQLDescribeCol and SQLColAttributes will return as to precision for
character data types (varchar, text, and unknown) in a result set.
This is more of a workaround for Postgres not being able to return the
defined column width of the varchar data type.
Maximum: always
return the maximum precision of the data type.
Dont Know: return "Dont Know"
value and let application decide.
Longest: return
the longest string length of the column of any row. Beware of this
setting when using cursors because the cache size may not be a good representation
of the longest column in the cache.
MS ACCESS: Seems to handle Maximum
setting ok, as well as all the others.
Borland: If sizes are large and lots of columns,
Borland may crash badly (it doesnt seem to handle memory allocation well)
if using Maximum size.
Data Type Options: affects
how some data types are mapped:
Text as LongVarChar:
Postgres TEXT type is mapped to SQLLongVarchar, otherwise SQLVarchar.
Unknowns as LongVarChar:
Unknown types (arrays, etc) are mapped to SQLLongVarChar, otherwise SQLVarchar
Bools as Char:
Bools are mapped to SQL_CHAR, otherwise to SQL_BIT.
Cache Size: When using
cursors, this is the row size of the tuple cache. If not using cursors,
this is how many tuples to allocate memory for at any given time.
The default is 100 rows for either case.
Max Varchar: The maximum
precision of the Varchar and BPChar(char[x]) types. The default is 254
which actually means 255 because of the null terminator. Note, if
you set this value higher than 254, Access will not let you index on varchar
columns!
Max LongVarChar: The maximum
precision of the LongVarChar type. The default is 4094 which actually
means 4095 with the null terminator. You can even specify (-4) for
this size, which is the odbc SQL_NO_TOTAL value.
SysTable Prefixes: The
additional prefixes of table names to regard as System Tables. The
driver already treats names that begin with "pg_" as system tables.
Here you can add additional ones, such as data dictionary tables (dd_).
Separate each prefix with a semicolan (;)
Connect Settings: These commands
will be sent to the backend upon a successful connection. Use
a semi-colan (;) to separate commands. This can now handle any query,
even if it returns results. The results will be thrown away however!
Advanced Options (<DataSource>
OR Connection) Dialog Box
ReadOnly: Whether the
datasource will allow updates. For new datsources, the default value
comes from the Advanced Options (Driver) dialog box.
6.2 Protocol: Forces driver
to use Postgres 6.2 protocol, which had different byte ordering, protocol,
and other semantics.
Connect Settings: The
driver sends these commands to the backend upon a successful connection.
It sends these settings AFTER it sends the driver "Connect Settings".
Use a semi-colan (;) to separate commands. This can now handle any
query, even if it returns results. The results will be thrown away
however!
Row Versioning: Allows
applications to detect whether data has been modified by other users while
you are attempting to update a row. It also speeds the update process
since every single column does not need to be specified in the where clause
to update a row. The driver uses the "xmin" system field of Postgres
to allow for row versioning. Microsoft products seem to use this
option well. See the faq
for details on what you need to do to your database to allow for the row
versioning feature to be used.
Show System Tables: The
driver will treat system tables as regular tables in SQLTables. This
is good for Access so you can see system tables.
OID Options:
Show Column - Includes the OID
in SQLColumns. This is good for using as a unique identifier to update
records if no good key exists OR if the key has many parts, which
blows up the backend.
Fake Index - This option
fakes a unique index on OID. This is useful when there is not a real
unique index on OID and for apps which can't ask what the unique identifier
should be (i.e, Access 2.0).