the driver will parse an SQL query statement to identify the columns and\r
tables and gather statistics about them such as precision, nullability,\r
aliases, etc. It then reports this information in SQLDescribeCol,\r
-SQLColAttributes, and SQLNumResultCols. <b>Prior to Postgres 6.4,\r
+SQLColAttributes, and SQLNumResultCols. <b>Prior to PostgreSQL 6.4,\r
this was the only accurate way of getting information on precision from\r
a query result.</b><br><br>\r
\r
what SQLDescribeCol and SQLColAttributes will return as to precision for\r
character data types (varchar, text, and unknown) in a result set when\r
the precision is unknown. <b>This was more of a workaround for pre-6.4\r
-versions of Postgres not being able to return the defined column width\r
+versions of PostgreSQL not being able to return the defined column width\r
of the varchar data type</b>.<br><br>\r
\r
<ul>\r
<ul>\r
\r
<li><i>Text as LongVarChar</i>:\r
-Postgres TEXT type is mapped to SQLLongVarchar, otherwise SQLVarchar.</li>\r
+PostgreSQL TEXT type is mapped to SQLLongVarchar, otherwise SQLVarchar.</li>\r
\r
<li><i>Unknowns as LongVarChar</i>: Unknown types (arrays, etc) are mapped to SQLLongVarChar, otherwise SQLVarchar</li>\r
\r
applications to detect whether data has been modified by other users while\r
you are attempting to update a row. It also speeds the update process\r
since every single column does not need to be specified in the where clause\r
-to update a row. The driver uses the "xmin" system field of Postgres\r
+to update a row. The driver uses the "xmin" system field of PostgreSQL\r
to allow for row versioning. Microsoft products seem to use this\r
option well. See the <a "http://gborg.postgresql.org/project/psqlodbc/faq/faq.php">faq</a>\r
for details on what you need to do to your database to allow for the row\r
\r
<ul>\r
<li><b>6.2:</b> Forces driver to\r
-use Postgres 6.2 protocol, which had different byte ordering, protocol,\r
+use PostgreSQL 6.2 protocol, which had different byte ordering, protocol,\r
and other semantics.<br /> </li>\r
\r
<li><b>6.3</b>: Use the 6.3 protocol. This is compatible\r
</ul>\r
\r
</body>\r
-</html>
\ No newline at end of file
+</html>\r
\r
<h1>psqlODBC FAQ</h1>\r
\r
- <p>Last updated: $Date: 2005/09/06 15:19:13 $</p>\r
+ <p>Last updated: $Date: 2005/10/11 07:47:11 $</p>\r
\r
<P>Current maintainer: Dave Page (<a href="mailto:dpage@postgresql.org">dpage@postgresql.org</a>)</p>\r
\r
which?) so in order to use row versioning, you must overload the int4eq function \r
for use with the xid type. Also, you need to create an operator to compare xid to \r
int4. You must do this for each database you want to use this feature on. This will \r
- probably not be necessary in Postgres 6.4 since it will be added. Here are the details:\r
+ probably not be necessary in PostgreSQL 6.4 since it will be added. Here are the details:\r
</p>\r
<pre>\r
create function int4eq(xid,int4)\r
Large objects are mapped to LONGVARBINARY in the driver to allow storing things like OLE \r
objects in Microsoft Access. Multiple SQLPutData and SQLGetData calls are usually used to \r
send and retrieve these objects. The driver creates a new large object and simply inserts \r
- its 'identifier' into the respective table. However, since Postgres uses an 'Oid' to identify \r
- a Large Object, it is necessary to create a new Postgres type to be able to discriminate \r
+ its 'identifier' into the respective table. However, since PostgreSQL uses an 'Oid' to identify \r
+ a Large Object, it is necessary to create a new PostgreSQL type to be able to discriminate \r
between an ordinary Oid and a Large Object Oid. Until this new type becomes an official \r
- part of Postgres, it must be added into the desired database and looked up for each connection. \r
+ part of PostgreSQL, it must be added into the desired database and looked up for each connection. \r
The type used in the driver is simply called "lo" and here is the command used to create it:\r
</p>\r
<pre>\r
<p>\r
Another important note is that this new type is lacking in functionality. It will not cleanup after \r
itself on updates and deletes, thus leaving orphans around and using up extra disk space. And \r
- currently, Postgres does not support the vacuuming of large objects.\r
+ currently, PostgreSQL does not support the vacuuming of large objects.\r
</p>\r
<p>\r
It would not be too difficult to write a interim stand-alone cleanup process to run at some interval \r
The question marks are replaced with the key values\r
</p>\r
<p>\r
- Prior to Postgres 6.4, this was a major problem. But there are at least 2 fixes in place for this as \r
+ Prior to PostgreSQL 6.4, this was a major problem. But there are at least 2 fixes in place for this as \r
of 6.4. One of the fixes is called KSQO (Keyset Query Optimization). As of 6.4, the driver now turns \r
this on by default, although this can be changed in the Advanced Driver options settings.\r
</p>\r
<ul>\r
<li>Check Text as LongVarchar</li>\r
<li>Uncheck Unknowns as LongVarchar</li>\r
- <li>Parse Statements option: Enable it, if using a protocol earlier than Postgres 6.4</li>\r
+ <li>Parse Statements option: Enable it, if using a protocol earlier than PostgreSQL 6.4</li>\r
<li>Unknown Sizes Options: Set to "Longest"</li>\r
</ul>\r
\r
When using the 6.4 protocol, this problem should not be an issue.\r
</p>\r
<p>\r
- Prior to the Postgres 6.4 protocol, the backend did not return the size of \r
+ Prior to the PostgreSQL 6.4 protocol, the backend did not return the size of \r
varchar/char datatypes in a query result and Borland relies heavily on this \r
for both simple queries and the data dictionary import. Therefore, there are \r
several driver options that were developed to help out with this.\r
\r
<h3><a name="6.3">6.3</a>) Why does MS Access sometimes complain about a GROUP BY or ORDER BY not being in the target list?</h3>\r
<p>\r
- This message comes from the PostgreSQL backend. Postgres currently requires fields \r
+ This message comes from the PostgreSQL backend. PostgreSQL currently requires fields \r
in the ORDER BY and GROUP BY clauses to be included in the target list. However, \r
this restriction has been lifted in PostgreSQL 6.4+\r
</p>\r
empty string.\r
</p>\r
<p>\r
- So when Access retrieves a row from PostgreSQl with fields containing the empty string, it \r
+ So when Access retrieves a row from PostgreSQL with fields containing the empty string, it \r
automatically translates them into NULL values. When you try updating this row, the query sent \r
from Access 2000 to PostgreSQL will fail to update the row. An example:\r
</p>\r
</i>\r
<br><br>\r
\r
-<h2>Using Large Objects for handling LongVarBinary (OLE Objects in Access)</h2>
-
-<p>Large objects are mapped to LONGVARBINARY in the driver to allow storing things like
-OLE objects in Microsoft Access. Multiple SQLPutData and SQLGetData calls are usually
-used to send and retrieve these objects. The driver creates a new large object and simply
-inserts its 'identifier' into the respective table. However, since Postgres uses an 'Oid'
-to identify a Large Object, it is necessary to create a new Postgres type to be able
-to discriminate between an ordinary Oid and a Large Object Oid. Until this new type
-becomes an official part of Postgres, it must be added into the desired database and
-looked up for each connection. The type used in the driver is simply called "lo" and
-here is the command used to create it:</p>
+<h2>Using Large Objects for handling LongVarBinary (OLE Objects in Access)</h2>\r
+\r
+<p>Large objects are mapped to LONGVARBINARY in the driver to allow storing things like\r
+OLE objects in Microsoft Access. Multiple SQLPutData and SQLGetData calls are usually\r
+used to send and retrieve these objects. The driver creates a new large object and simply\r
+inserts its 'identifier' into the respective table. However, since PostgreSQL uses an 'Oid'\r
+to identify a Large Object, it is necessary to create a new PostgreSQL type to be able\r
+to discriminate between an ordinary Oid and a Large Object Oid. Until this new type\r
+becomes an official part of PostgreSQL, it must be added into the desired database and\r
+looked up for each connection. The type used in the driver is simply called "lo" and\r
+here is the command used to create it:</p>\r
\r
<blockquote>\r
-<pre>
+<pre>\r
create type lo (\r
internallength=4,\r
externallength=10,\r
input=int4in,\r
- output=int4out,
+ output=int4out,\r
default='',\r
passedbyvalue\r
-);
+);\r
</pre>\r
</blockquote>\r
-
-<p>Once this is done, simply use the new 'lo' type to define columns in that database. Note
-that this must be done for each database you want to use large objects in with the driver.
-When the driver sees an 'lo' type, it will handle it as LONGVARBINARY.</p>
-
-<p>Another important note is that this new type is lacking in functionality. It will not
-cleanup after itself on updates and deletes, thus leaving orphans around and using up
-extra disk space. And currently, Postgres does not support the vacuuming of large
-objects. Hopefully in the future, a real large object data type will be available.</p>
-
-<p>But for now, it sure is fun to stick a Word document, Visio document, or avi of a dancing
+\r
+<p>Once this is done, simply use the new 'lo' type to define columns in that database. Note\r
+that this must be done for each database you want to use large objects in with the driver.\r
+When the driver sees an 'lo' type, it will handle it as LONGVARBINARY.</p>\r
+\r
+<p>Another important note is that this new type is lacking in functionality. It will not\r
+cleanup after itself on updates and deletes, thus leaving orphans around and using up\r
+extra disk space. And currently, PostgreSQL does not support the vacuuming of large\r
+objects. Hopefully in the future, a real large object data type will be available.</p>\r
+\r
+<p>But for now, it sure is fun to stick a Word document, Visio document, or avi of a dancing\r
baby into a database column, even if you will fill up your server's hard disk after a while!</p>\r
\r
</body>\r
-</html>
\ No newline at end of file
+</html>\r
<br>\r
<ul>\r
<li>DAO, ADO and RDO interfaces available in VB</li>\r
-<li>Created the lo type using the appropriate functions available in contrib/lo in the Postgresql source tree</li>\r
-<li>Installed and properly configured the latest version of the Postgresql ODBC driver.</li>\r
+<li>Created the lo type using the appropriate functions available in contrib/lo in the PostgreSQL source tree</li>\r
+<li>Installed and properly configured the latest version of the PostgreSQL ODBC driver.</li>\r
</ul>\r
\r
In the example the database used has one table with only two fields. Here is the SQL definition:\r
</p>\r
\r
</body>\r
-</html>
\ No newline at end of file
+</html>\r
\r
<li><a href="unix-compilation.html">Compiling psqlODBC on Unix systems.</a><br> </li>\r
\r
- <li><a href="faq.html">frequently Asked Questions (FAQ).</a><br> </li>\r
+ <li><a href="faq.html">Frequently Asked Questions (FAQ).</a><br> </li>\r
</ul>\r
\r
<h2>psqlODBC HOWTOs</h2>\r
projects / psqlodbc.git / commitdiff