[unixODBC-dev] FDB

Peter Harvey pharvey at peterharvey.org
Mon Nov 22 18:09:25 GMT 2004


Nick Gorham wrote:

> Peter Harvey wrote:
>
>> Nick,
>>
>> Mind if I add;
>>
>> --with-fdb         Build File DataBase [default=no]
>>
>> to configure.in (and Makefile.am)?
>>
>> Peter
>
>
> Not at all, what does it do ?
>

This is work that I never quite completed - about 2 years ago. I think 
Lorne may have done some work on it since - not sure. But it it is data 
access code - it combines elements of SQL, ODBC, and dBase.

I guess it can be described as layers.

Layer 1
- DOT Prompt
--------------------------------

There is an executable (ifdb) which strives to be like  the old .DOT 
prompt program from dBase but with the advantage of being able to use a 
more flexible/extendable back-end. It combines aspects of unixODBC isql 
in that it uses a driver manager to switch out the back-end but then 
uses record based commands (dot prompt) to work with the data instead of 
SQL. The parser for the DOT commands is implemented in libIFDB.

Layer 2
- Driver Manager
--------------------------------

There is a library (libFDB) which acts as a Driver Manager. Similar to 
the ODBC DM it provides the same interface as a driver and loads/unloads 
the driver but it works using a record oriented API which more closely 
reflects xBase commands.

Layer 3
- Driver
--------------------------------

One driver (libFDBXB) has been created. This driver works with xBase 
files (dbf,ntx,,dbt). The driver brings together the functionality 
provided by the relevant I/O libraries such as a data file and an index 
file.

Layer 3
- I/O
--------------------------------

A set of stand alone libraries (libNTXIO, libNDXIO, libDBFIO, libDBTIO) 
have been create or started.


The ultimate goal is to create an ODBC driver which wraps Layer 2 - 
thereby providing a single ODBC driver for supporting a wide variety of 
file-based data sources. I suppose I/O libraries could be written for 
other, specialty, data sources such as live feeds via sockets/ports - 
whatever.  An SQL engine feature would have to be provided - probably in 
Layer 2 (the driver manager). The focus is more on flexability and 
extendability and less on performance.

Peter




More information about the unixODBC-dev mailing list