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