Tim Goeke Thomas Lockhart 1998-08-25 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 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. 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. For Visual C++ you can find out more at Microsoft's web site or in your docs. 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. 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 driver can be built in a standalone, client-only installation, or can be built as a part of the main Postgres distribution. The standalone installation is convenient if you have ODBC client applications on multiple, heterogeneous platforms. The integrated installation is convenient when the target client is the same as the server, or when the client and server have similar runtime configurations. For an integrated installation, specify the --with-odbc command-line argument for src/configure: ./configure --with-odbc Once configured, the ODBC driver will be built and installed into the areas defined for the other components of the Postgres system. The installation-wide ODBC configuration file will be placed into the top directory of the Postgres target tree (POSTGRESDIR). This can be overridden from the make command-line as % make ODBCINST=filename A standalone installation is not integrated with or built on the normal Postgres distribution. It should be best suited for building the ODBC driver for multiple, heterogeneous clients who do not have a locally-installed Postgres source tree. The standalone installation distribution can be built from the Postgres distribution or may be obtained from Insight Distributors, the current maintainers of the non-Unix sources. To create a tar file for a complete standalone installation, first configure the main Postgres distribution. Then, create the tar file: % cd interfaces/odbc % make standalone Copy the output tar file to your target system, unpack it into a clean directory, and then: % ./configure --with-odbcinst=instfile % make POSTGRESDIR=targettree ODBCINST=instfile The ODBCINST can be specified on either or both command lines. If you would like to install components into different trees, then you can specify various destinations explicitly: % make BINDIR=bindir LIBDIR=libdir HEADERDIR=headerdir ODBCINST=instfile ~/.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 psqlODBC has been built and tested on Linux. There have been reports of success with FreeBSD and with Solaris.