Received: from golem.jpl.nasa.gov (root@hectic-3.jpl.nasa.gov
[128.149.68.205])
by hub.org (8.8.8/8.8.8) with ESMTP id KAA10419
for ;
Sat, 3 Oct 1998 10:29:56 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (localhost [127.0.0.1])
by golem.jpl.nasa.gov (8.8.5/8.8.5) with ESMTP id OAA20893;
Sat, 3 Oct 1998 14:30:24 GMT
Sender: tgl@mythos.jpl.nasa.gov
Message-ID: <361634FE.68273D44@alumni.caltech.edu>
Date: Sat, 03 Oct 1998 14:30:22 +0000
From: "Thomas G. Lockhart"
Organization: Caltech/JPL
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i686)
MIME-Version: 1.0
To: Gerald Gryschuk
CC: Byron Nikolaidis ,
pgsql-interfaces
Subject: Re: Just some unfinished stuff.
References: <360C90C5.7A466671@home.com>
<3614ED17.B0CA4B66@alumni.caltech.edu>
<3615D4A1.B061C1C7@home.com>
Content-Type: multipart/mixed; boundary="------------1FDA1DE0AC8A6EFC5EEF5D5B"
This is a multi-part message in MIME format.
--------------1FDA1DE0AC8A6EFC5EEF5D5B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > Speaking of docs, Byron, do you have a preference for how we will do
> > nice docs for the distribution? I've got some sgml source code for
> > Unix-side issues, but have not integrated any other information.
> > Could you summarize what docs resources currently exist, and which
> > ones you would like to see in the future?
> Oh goody. Real docs. I was hoping someone else would do them. Can I
> assume that if your writing "nice docs" that I don't have to write
> that new Readme I mentioned?
Well, I have good new and bad news...
First, the good news: We will have real odbc docs for this release.
Now the bad news: I'd like you to contribute to them *grin*
I've enclosed the existing sgml source and the html output (so you can
see what it looks like) for the odbc docs I've adapted and written.
afaik it doesn't have any of the generic or WIN32 info from Byron's
docs, but it should try to cover the Unix-specific stuff at least.
Could you look at it and add information you think is important? If you
get confused on the sgml markup just type in plain text in about the
right place without markup and I'll fix it up after you send it back
(maybe you can mark things with a "***" or "GGG" to make sure I find the
un-marked-up changes, if any).
At the moment I've got these docs in the Programmer's Guide, but I think
they should show up somewhere else, in either the User's Guide or the
Admin's Guide. Which would you vote for?
- Tom
--------------1FDA1DE0AC8A6EFC5EEF5D5B
Content-Type: text/html; charset=us-ascii; name="odbc.sgml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="odbc.sgml"
Content-Base: "file:/opt/postgres/current/doc/src/sgm
l/odbc.sgml"
TimGoekeThomasLockhart1998-08-25ODBC Interface
Background information originally by
Tim Goeke
ODBC (Open Database Connectivity) is an abstract
API
which allows you to write standard "ODBC" applications.
ODBC provides a product-neutral interface
between frontend applications and database servers,
allowing a user or developer to write applications which are portable among servers.
Background
The ODBC API matches up
on the backend to an ODBC-compatible data source.
This could be anything from a text file to an Oracle or
Postgres RDBMS.
The backend access come from ODBC drivers, or vendor specifc drivers that
allow data access. psqlODBC is such a driver, along with others that are
available, such as the OpenLink ODBC drivers.
Once you write an ODBC application, you SHOULD be able to connect to ANY
back end database, regardless of the vendor, as long as the database schema
is the same.
For example. you could have MS SQL Server
and Postgres servers which have
exactly the same data. Using ODBC, your Windows app would make exactly the
same calls and the back end data source would look the same (to the windows
app).
Insight Distributors provides active and ongoing
support for the core psqlODBC distribution. They provide a
FAQ, ongoing development
on the code base, and actively participate on the
interfaces mailing list.
Windows Applications
In the real world, differences in drivers and the level of ODBC support
lessens the potential of ODBC:
Access, Delphi, and Visual Basic all support ODBC directly.
Under C++, such as Visual C++, you can use the C++ ODBC API.
In Visual C++, you can use the CRecordSet class, which wraps the
ODBC API
set within an MFC 4.2 class. This is the easiest route if you are doing
Windows C++ development under Windows NT.
If I write an app for Postgres
can I write it using ODBC calls
to the Postgres server, or is that only when another database program
like MS SQL Server or Access needs to access the data?
Again, the ODBC API set is the way to go.
You can find out more at
Microsoft's web site or in your Visual C++ docs (if that's what you are using.)
Visual Basic and the other RAD tools have Recordset objects that use ODBC
directly to access data. Using the data-aware controls, you can quickly
link to the ODBC back end database (very quickly).
Playing around with MS Access will help you sort this out. Try using
File->Get External Data
You'll have to set up a DSN first.
Unix ApplicationsApplixWare has an ODBC database interface
supported on at least some platforms. ApplixWare v4.4.1 has been
demonstrated under Linux with Postgres v6.4
using the psqlODBC
driver contained in the Postgres distribution.
Configuration Files
The ~/.odbc.ini contains user-specified access information
for the psqlODBC
driver. The file uses conventions typical for Windows
Registry files, but despite this
restriction can be made to work.
Here is an example .odbc.ini file,
showing access information for three databases:
[ODBC Data Sources]
DataEntry = Read/Write Database
QueryOnly = Read-only Database
Test = Debugging Database
Default = Postgres Stripped
[DataEntry]
ReadOnly = 0
Servername = localhost
Database = Sales
[QueryOnly]
ReadOnly = 1
Servername = localhost
Database = Sales
[Test]
Debug = 1
CommLog = 1
ReadOnly = 0
Servername = localhost
Username = tgl
Password = "no$way"
Port = 5432
Database = test
[Default]
Servername = localhost
Database = tgl
Driver = /opt/postgres/current/lib/libpsqlodbc.so
[ODBC]
InstallDir = /opt/applix/axdata/axshlib
For Applix, here is an example ~/axhome/macros/login.am file:
macro login
set_set_system_var@("sql_username@","tgl")
set_system_var@("sql_passwd@","no$way")
endmacro
Supported PlatformspsqlODBC has been built and tested
on Linux. There have been reports of success
with FreeBSD and with Solaris.
--------------1FDA1DE0AC8A6EFC5EEF5D5B
Content-Type: text/html; charset=us-ascii; name="odbc.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="odbc.htm"
Content-Base: "file:/opt/postgres/current/doc/src/sgm
l/odbc.htm"
ODBC Interface
Note: Background information originally by
Tim Goeke
ODBC (Open Database Connectivity) is an abstract
API
which allows you to write standard "ODBC" applications.
ODBC provides a product-neutral interface
between frontend applications and database servers,
allowing a user or developer to write applications which are portable among servers.
The ODBCAPI matches up
on the backend to an ODBC-compatible data source.
This could be anything from a text file to an Oracle or
PostgresRDBMS.
The backend access come from ODBC drivers, or vendor specifc drivers that
allow data access. psqlODBC is such a driver, along with others that are
available, such as the OpenLink ODBC drivers.
Once you write an ODBC application, you SHOULD be able to connect to ANY
back end database, regardless of the vendor, as long as the database schema
is the same.
For example. you could have MS SQL Server
and Postgres servers which have
exactly the same data. Using ODBC, your Windows app would make exactly the
same calls and the back end data source would look the same (to the windows
app).
Insight Distributors provides active and ongoing
support for the core psqlODBC distribution. They provide a
FAQ, ongoing development
on the code base, and actively participate on the
interfaces mailing list.
In the real world, differences in drivers and the level of ODBC support
lessens the potential of ODBC:
Access, Delphi, and Visual Basic all support ODBC directly.
Under C++, such as Visual C++, you can use the C++ ODBCAPI.
In Visual C++, you can use the CRecordSet class, which wraps the
ODBCAPI
set within an MFC 4.2 class. This is the easiest route if you are doing
Windows C++ development under Windows NT.
If I write an app for Postgres
can I write it using ODBC calls
to the Postgres server, or is that only when another database program
like MS SQL Server or Access needs to access the data?
Again, the ODBCAPI set is the way to go.
You can find out more at
Microsoft's web site or in your Visual C++ docs (if that's what you are using.)
Visual Basic and the other RAD tools have Recordset objects that use ODBC
directly to access data. Using the data-aware controls, you can quickly
link to the ODBC back end database (very quickly).
Playing around with MS Access will help you sort this out. Try using
File->Get External Data
ApplixWare has an ODBC database interface
supported on at least some platforms. ApplixWare v4.4.1 has been
demonstrated under Linux with Postgres v6.4
using the psqlODBC
driver contained in the Postgres distribution.
The ~/.odbc.ini contains user-specified access information
for the psqlODBC
driver. The file uses conventions typical for Windows
Registry files, but despite this
restriction can be made to work.
Here is an example .odbc.ini file,
showing access information for three databases: