Home Web Design Programming Fairlight CMI Soap Box Downloads Links Biography About... Site Map

The Holmes Page Introduction to RDDs

CA-Clipper Opportunities Tips and Tricks Networking Internal Errors Source Code CA-VO


The CA-Clipper replaceable database driver (RDD) technology allows you to swap in a different data-handling "engines", while leaving your source code relatively unchanged.
As the CA-Clipper documentation explains:
      "The CA-Clipper database system supports a driver architecture that makes CA-Clipper-compiled applications data format independent. Such applications can, therefore, access the data formats of other database systems, including the dBASE IV (.MDX), FoxPro (.CDX), and Paradox (.DB) formats on a variety of equipment."      

When you link one or more RDDs into your application, you get automatic access to data and index files created by other database products.
CA-Clipper comes with several RDDs that provide access to database, memo, and index file formats of several popular database products.
      • DBFCDX  for FoxPro 2 tables and indexes
• DBFMDXfor dBase IV tables and indexes
• DBFNDXfor dBase III tables and indexes
• DBFNTXfor CA-Clipper tables and indexes  default
• DBPX for Paradox 3.5 tables and indexes
The default DBFNTX RDD works for most "normal" CA-Clipper applications and is generally backwards compatible with earlier versions of CA-Clipper, although there have been changes in index file formats and locking schemes.
To use an RDD you need request it to make sure it gets linked in, and then you need to open your table with it. Like this:
      request DBFNTX
set index to MYTABLE
In most of the RDDs (DBFxxx), the DBF file format is the same, but the memofile formats differ. For example, DBFCDX memofiles have an extension of FPT, while DBFNTX uses DBT. Internally, the two store data differently. In addition, different RDDs lock records differently. See my Data Locking page for some examples.
Another difference between file formats is the limits. For example, dBase and the DBFNDX RDD allow only 256 fields per table, whereas DBFNTX and DBFCDX allow 4096. Also, with the DBFNTX and DBFCDX drivers the fields can be longer (up to 64k bytes).
Many RDDs give you new and enhanced commands and functions, but the CA-Clipper data driver architecture can hide most of the differences, often making it fairly straightforward to swap in a new RDD at any time. One of the most common issues when dealing with different RDDs is file extensions. You'll notice that in the example above the NTX extension was not given in the set index to command. The RDD supplies an appropriate extension.

Inside the RDD

An RDD is really a LIB file, which is a collection of functions, usually written in C or assembler for performance. The functions in the RDD library are written according to a set of "rules" so that the CA-Clipper data engine can interact properly with the RDD.
When your program starts, the RDD calls an initialization function to create a list of all of the functions in the driver. The functions are listed in a specific order but there may be "gaps", or missing functions, which are filled in by the functions from the parent data driver. The end result is a complete set of functions that can handle all possible data requests for the RDD.
When a file is opened with the RDD, a data structure is created in memory which contains the list of functions as well as values such as the workarea, alias, count of fields, bof flag, eof flag, and the filter and relations. Every workarea has its own data structure which allows each workarea to use a different RDD.
When your program asks for a specific data function, such as dbgotop() (which is the same as the go top command), the CA-Clipper data engine looks for the matching RDD function in the function list of the workarea's data structure. As an example, the "go top" function is the 7th one in the function list. To see the list of functions, look for typedef struct _DBFUNCTABLE_ in CLIPPER\INCLUDE\RDD.API.
RDDs are similar in principle to the ODBC (Open Database Connectivity) technology in Windows, although RDDs arrived earlier. Both provide a middle layer that sits between the program and the underlying database. Ideally, the source code of the front-end program will remain the same, even if the back-end database changes. Interestingly, ODBC has a limit of only 256 fields per table (remember DBFNTX allows up to 4096).

Different RDDs

There are third-party RDDs available for data formats other than DBF, for example Btrieve, Oracle, and SQL. Some of the CA-Clipper RDDs connect a DOS application running in a Windows DOS box to a Windows ODBC driver which allows ODBC access to SQL data from a DOS-based CA-Clipper app. (Does that make sense?)
A popular RDD is the SIx RDD from SuccessWare, which is a kind of enhanced DBFCDX driver (which was also written by SuccessWare). Beyond basic data access capability it supports data encryption, compression, triggers, and transactions, along with a query optimizer, fast text search, and many other features.
Another great RDD is the Advantage Database Server. It connects a CA-Clipper app to a NetWare or Windows NT server where all of the data is stored and where the indexing and seeking is performed. Performance jumps 3 or 4 times over the DBFNTX driver, not to mention that index file "corruption" goes away. Because the disk-intensive tasks are performed at the server rather than at the client, even the Internet can be used as a WAN. I recommend this RDD to all of my clients.
There are other RDDs that come to mind. One is UltiRoute, which acts as a gateway to SQL data on a mini or mainframe. And there is also OpenPath, which is similar. Both of these products require more extensive changes to your source code because of the SQL methodology where everything is a "set" or "subset" of records. For example, recno() is either not supported, or it refers to the position in the current set rather than in the entire table. Another difference is that records are deleted immediately, with no chance of recall.
In contrast, Advantage Database Server typically requires only 2 lines of code to be added to the main module of the program!
So, depending on the back-end data format, using the appropriate RDD may be a simple matter of re-linking, or it may represent a lot of work to alter the source code to fit the back-end engine.

Home Web Design Programming Fairlight CMI Soap Box Downloads Links Biography About... Site Map

Site Map Send comments about this site to Greg at gregh@ghservices.com
All pages copyright © 1996-2002 GH Services™   Created 1998/08/12   Last updated 2002/07/12
All trademarks contained herein are the property of their respective owners