Someone in a position of authority once insisted on repeating that filepro was a relational database. I argued, but they never took my arguments seriously. Perhaps if I lay these arguments out in a nice table, they'll be taken more seriously.

see Dr. E.F. Codd's 12 rules of a relational database

Rule Number Filepro Complies? Detail
Number 1: Data is presented in tables Yes There is no physical relationship between tables, nor a hierarchical ranking of them. Tables are laid out in rows and columns.
Number 2: Data is logically accessible Mostly The order in which data is stored in a file is irrelevant to it's retrieval. However, there is still the concept of record ID, which is a system-assigned unique ID. However, columns are not stored in logical, but in physical order. So one cannot retrieve the value from "zip code" field, unless you happen to know that zip code is stored in column number 4.
Number 3: Nulls are treated uniformly as unknown No Null does not exist in filepro.
Number 4: Database is self-describing No It is not possible within filepro to find the name of a column. The filesystem contains data about the database, rather than the database itself. Each table does, however, contain metadata about that table, such as who created a record, when was it updated, et al.
Number 5: A single language is used to communicate with the DBMS Not really the programming language which alters data has commands which are only active during certain types of code invocation. There is no provision for administration from the data access language. Data Definition cannot be done from the code. Furthermore, code for specifying record selections can be done in one of two different syntaxes
Number 6: Provides alternatives for viewing data No There is no concept of 'views' or 'virtual tables' in filePro. Instead, temporary REAL tables are used.
Number 7: Supports set-based or relational operations Not really No. Records can be selected by a variety of means, but code must be written to deal with each individual record within the set. Furthermore, code which is used to select records is generally non-accessible from code used to modify records.
Number 8: Physical Data Independence Somewhat while the code can withstand changes in column layouts, and column sizing, there are still steps for physically resizing the database files.
Number 9: Logical Data Independence Mostly relationships among tables cannot be specified, so altering logical relationships will not necessarily break an application. All relationships must be done in user-developed code.
Number 10: Data Integrity is a function of the DBMS Absolutely Not The DBMS itself cannot enforce data integrity. All code must enforce the integrity, or edits must be specified which enforce the integrity. Even if edits are defined, however, there is no way to prevent rogue code from putting invalid data in a field.
Number 11: Supports Distributed Operations Not at all This isn't even on their roadmap.
Number 12: Data Integrity cannot be subverted No. Anyone with a copy of perl can make low level alterations to the data. You just have to write your own routines for tweaking with the data. God help you if you screw up the formatting.
Note that other databases do not pass all 12 rules. I believe, however, that filePro fails enough of these criteria that it should NOT be called an RDBMS
Back to the index page