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" Tim Goeke Thomas Lockhart 1998-08-25 ODBC 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. <productname>Windows</productname> 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 Applications 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. 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 Platforms psqlODBC 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

Chapter 19. 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.

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.

--------------1FDA1DE0AC8A6EFC5EEF5D5B Content-Type: text/html; charset=us-ascii; name="odbc4084.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="odbc4084.htm" Content-Base: "file:/opt/postgres/current/doc/src/sgm l/odbc4084.htm" Windows Applications

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

Tip: You'll have to set up a DSN first.

--------------1FDA1DE0AC8A6EFC5EEF5D5B Content-Type: text/html; charset=us-ascii; name="odbc4114.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="odbc4114.htm" Content-Base: "file:/opt/postgres/current/doc/src/sgm l/odbc4114.htm" Unix Applications

Unix Applications

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.

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

--------------1FDA1DE0AC8A6EFC5EEF5D5B Content-Type: text/html; charset=us-ascii; name="odbc4134.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="odbc4134.htm" Content-Base: "file:/opt/postgres/current/doc/src/sgm l/odbc4134.htm" Supported Platforms

Supported Platforms

psqlODBC has been built and tested on Linux. There have been reports of success with FreeBSD and with Solaris.

--------------1FDA1DE0AC8A6EFC5EEF5D5B--