Press this button to restore the normal defaults for the settings described below.
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.
Deprecated for 7.1+ servers. Check this option when connecting 7.0- servers and the application seems to be suffering from the following kind of queries:
SELECT ...
FROM ...
WHERE ( a=1 AND b=1 AND c=1 )
OR ( a=1 AND b=1 AND c=2 )
Check this option.
If true, 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.
Tell the driver how to gather the information about result columns of queries. See also Disallow Premature and ServerSide Prepare options. The driver checks this option first.
If disabled then it checks the Server Side Prepare option. If disabled also it checks the Disallow Premature option. If neither of them is specified the driver would execute the prepared statement prematurely when the application inquires the result columns' info. If this option is 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.
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.
Log communications to/from the backend to that file. This is good for debugging problems. The file name for the log follows the naming convention psqlodbc_xxxx.log.
Log debug messages to that file. This is good for debugging problems with the driver. The file name for this log follows the naming convention mylog_xxx.log.
This controls what SQLDescribeCol and SQLColAttributes will return as to precision for character data types (varchar, text, and unknown) in a result set when the precision is unknown.
The following options affects how some data types are mapped.
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!
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.
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.
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 semicolon (;).
Whether the datasource will allow updates.
The driver will treat system tables as regular tables in SQLTables. This is good for Access so you can see system tables.
Convert Unix style line endings to DOS style.
Enable updateable cursor emulation in the driver.
Allow the use of bytea columns for Large Objects.
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 PostgreSQL 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.
Mainly for 7.1 to 7.3 servers. Server side prepare is a more preferable option for 7.4+ servers.
Tell the driver how to gather the information about result columns. See also Parse Statements and Server Side Prepare options.
This is an option to compensate for the lack of a server's Prepare functionality. For example, (Middleware) applications issue the following ODBC API calls.
SQLPrepare( hstmt, "SELECT ...", .. )
In most cases they have to know how many fields, what kind of fields they would return and so they would issue SQLNumResultCols and/or SQLDescribeCols/ SQLColAttribute etc.
The problem is how the psqlODBC driver answers the inquiry. PostgreSQL hadn't provided the Prepare functionality until 7.4 and we couldn't ask the backend about it directly.
When using Disallow Premature, the driver will get the column info as follows:
BEGIN; --(unless in a transaction)
DECLARE CURSOR ... FOR SELECT ... ;
FETCH BACKWARD IN ... ;
CLOSE ... ;
The driver gets the field info using the fetch backward's result. The fetch backward command returns no row but returns the field info. Though the command is expected to be returned immediately it isn't true for 7.0- servers unfortunately. The 7.1 or later servers do seem to return from the fetch backward command immediately.
Represent TRUE as -1 for compatibility with some applications.
Applicable for 7.3+ servers and recommended for 7.4+.
For PostgreSQL versions 7.4+ and newer, this options tells the driver how to gather the information about result columns. See also Parse Statement and Disallow Premature options.
By using extended query protocol the driver replies to the inquiry correctly and effectively.
By using extended query protocol the driver replies to the inquiry for the information of parameters.
When using prepared statements, prepare them on the server rather than in the driver. This can give a slight performance advantage as the server doesn't need to re-parse the statement each time it is used.
GSSAPI use to AUTH_REQ_GSS request from a server.(only Windows)
Define what datatype to report int8 columns as.
combination of the following bits:
Note that when using SSL connections this setting is ignored.
Specifies what to rollback should an error occur.
Notes in a setup: This specification is set up with a PROTOCOL option parameter.
PROTOCOL = [ 6.2 | 6.3 | 6.4 | 7.4 ] [ - ( 0 | 1 | 2 ) ]
Default value is a sentence unit (it is a transaction unit before 8.0).
The driver sends these commands to the backend upon a successful connection. It sends these settings AFTER it sends the driver the Connect Settings.
Use a semi-colon (;) to separate commands. This can now handle any query, even if it returns results. The results will be thrown away however!
This dialog allows you to specify pre-connection/default logging options
Log communications to/from the backend to that file. This is good for debugging problems.
Log debug messages to that file. This is good for debugging problems with the driver.
Log debug messages to that file. This is good for debugging problems with the MSDTC.
Adjustment of write permission.
This dialog allows you to select which PostgreSQL ODBC driver to use for this connection. Note that this may not work with third party drivers.
There is a method of specifying a connection option in a keyword strings.
myConn = "ODBC;DRIVER={PostgreSQL};" & serverConn & _
"A0=0;A1=6.4;A2=0;A3=0;A4=0;A5=0;A6=;A7=100;A8=4096;A9=0;" & _
"B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;" & _
"C0=0;C1=0;C2=dd_"
Please refer to a keyword list for details.