Starting in the mid 1980s many other companies produced their own dialects or variations on the product and language. These included FoxPro (now Visual FoxPro), Arago, Force, dbFast, dbXL, Quicksilver, Clipper, Xbase++, FlagShip, Recital, CodeBase, MultiBase and Harbour/xHarbour. Together these are informally referred to as xBase.
dBase's underlying file format, the .dbf file, is widely used in many other applications needing a simple format to store structured data.
dBase features an IDE with a Command Window and Navigator, a just in time compiler, a preprocessor, a virtual machine interpreter, a linker for creating dBase application .exe's, a freely available runtime engine, and numerous two-way GUI design tools including a Form Designer, Report Designer, Menu Designer, Label Designer, Datamodule Designer, SQL Query Designer, and Table Designer. Two-way Tools refers to the ability to switch back and forth between using a GUI design tool and the Source Code Editor. Other tools include a Source Code Editor, a Project Manager that simplifies building and deploying a dBase application, and an integrated Debugger. dBase features structured exception handling and has many built-in classes that can be subclassed via single inheritance. There are visual classes, data classes, and many other supporting classes. Visual classes include Form, SubForm, Notebook, Container, Entryfield, RadioButton, SpinBox, ComboBox, ListBox, PushButton, Image, Grid, ScrollBar, ActiveX, Report, ReportViewer, Text, TextLabel and many others. Database classes include Session, Database, Query, Rowset, Field, StoredProc and Datamodule classes. Other classes include File, String, Math, Array, Date, Exception, Object and others. dBase objects can be dynamically subclassed by adding new properties to them at runtime.
According to Ratliff, the language in JPLDIS was a simple, command-driven language intended for interactive use on printing terminals. There is some evidence that JPLDIS was influenced by Tymshare Corporation's mainframe database product called RETRIEVE.
For handling data, dBase provided detailed procedural commands and functions to open and traverse records in data files (e.g., USE, SKIP, GO TOP, GO BOTTOM, and GO recno), manipulate field values (REPLACE and STORE), and manipulate text strings (e.g., STR() and SUBSTR()), numbers, and dates. Its ability to simultaneously open and manipulate multiple files containing related data led Ashton-Tate to label dBase a "relational database," even though it did not meet the criteria defined by Dr. Edgar F. Codd's relational model. (It could be better characterized as an application development language and integrated navigational database management system.)
dBase used a runtime interpreter architecture, which allowed the user to execute commands by typing them in a command line "dot prompt." Upon typing a command or function and pressing the return key, the interpreter would immediately execute or evaluate it. Similarly, program scripts (text files with PRG extensions) ran in the interpreter (with the DO command), where each command and variable was evaluated at runtime. This made dBase programs quick and easy to write and test because programmers didn't have to first compile and link them before running them. (For other languages, these steps were tedious in the days of single- and double-digit megahertz CPUs.) The interpreter also handled automatically and dynamically all memory management (i.e., no preallocating memory and no hexadecimal notation), which more than any other feature made it possible for a business person with no programming experience to develop applications.
Conversely, the ease and simplicity of dBase presented a challenge as its users became more expert and as professional programmers were drawn to it. More complex and more critical applications demanded professional programming features for greater reliability and performance, as well as greater developer productivity.
Over time, Ashton-Tate's competitors introduced so-called clone products and compilers that introduced more robust programming features such as user-defined functions (UDFs) to supplement the built-in function set, scoped variables for writing routines and functions that were less likely to be affected by external processes, arrays for complex data handling, packaging features for delivering applications as executable files without external runtime interpreters, object-oriented syntax, and interfaces for accessing data in remote database management systems. Ashton-Tate also implemented many of these features with varying degrees of success. Ashton-Tate and its competitors also began to incorporate SQL, the ANSI/ISO standard language for creating, modifying, and retrieving data stored in relational database management systems.
In the late 1980s, developer groups sought to create a dBase language standard (IEEE 1192). It was then that the language started being referred to as "Xbase" to distinguish it from the Ashton-Tate product. Hundreds of books have been written on dBase and Xbase programming.
In 1988 Ashton-Tate filed suit against Fox Software and The Santa Cruz Operation (SCO) for copying dBase's "structure and sequence" in FoxBase+ (SCO marketed XENIX and UNIX versions of the Fox products). In December of 1990, U.S. District judge Terry Hatter, Jr. dismissed Ashton-Tate's lawsuit and invalidated Ashton-Tate's copyrights for not disclosing that dBase had been based, in part, on the public domain JPLDIS. In October of 1991, while the case was still under appeal, Borland International acquired Ashton-Tate, and as one of the merger's provisions the U.S. Justice Department required Borland to end the lawsuit against Fox and allow other companies to use the dBase language without the threat of legal action.
Today, implementations of the dBase language have expanded to include many features targeted for business applications, including object-oriented programming, manipulation of remote and distributed data via SQL, Internet functionality, and interaction with modern devices.
REPLACE ALL salary WITH salary * 1.1 FOR supervises > 0
LIST ALL fname, lname, salary TO PRINT
* (comment: reserved words shown in CAPITALS for illustration purposes)
Note how one does not have to keep mentioning the table name. The assumed ("current") table stays the same until told otherwise. This is in contrast to SQL which almost always needs explicit tables. Because of its origins as an interpreted, dBase used a variety of contextual techniques to reduce the amount of typing needed. This facilitated incremental, interactive development but also made modular programming difficult. A tenet of modular programming is that the correct execution of a program module must not be affected by external factors such as the state of memory variables or tables being manipulated in other program modules. Because dBase was not designed with this in mind, developers had to be careful about porting (borrowing) programming code that assumed a certain context and it would make writing larger-scale modular code difficult. Work-area-specific references were still possible using the arrow notation ("B->customer") so that multiple tables could be manipulated at the same time.
Another notable feature is the re-use of the same clauses for different commands. For example, the FOR clause limits the scope of a given command. (It is somewhat comparable to SQL's WHERE clause). Different commands such as LIST, DELETE, REPLACE, BROWSE, etc. could all accept a FOR clause to limit (filter) the scope of their activity. This simplifies the learning of the language.
dBase was also one of the first business-oriented languages to implement string evaluation.
i = 2
myMacro = "i + 10"
i = &myMacro
// i now has the value 12
Here the "&" tells the interpreter to evaluate the string stored in "myMacro" just like it was programming code. This is an example of a feature that made dBase programming flexible and dynamic, sometimes called "meta ability" in the profession. However, it could also be problematic for pre-compiling and for making programming code secure from hacking. However, dBase tended to target custom applications for small and medium companies where compile-based security was often less of an issue. For example, nobody would contemplate writing an operating system in the language.
As an application development platform, dBase fills a gap between lower level languages such as C, C++, and Java and high-level proprietary 4GLs (fourth generation languages) and purely visual tools, providing relative ease-of-use for business people with less formal programming skill and high productivity for professional developers willing to trade off the low-level control.
dBase remained a popular teaching tool even after sales slowed because the text-oriented commands were easier to present in printed training material than the mouse-oriented competitors. (Mouse-oriented commands were added to the product over time, but the command language remained a popular de-facto standard while mousing commands tended to be vendor-specific.)
dBase 3+ and dBase IV came packaged with an ASSIST (see the photo at the top of page) application to manipulate data and queries, as well as a APPSGEN application which allowed the user to generate applications without resorting to code writing like a 4GL. The dBASE IV APGEN tool was based largely on portions of an early CP/M product named Personal Pearl.
dBase's database system was one of the first to provide a header section for describing the structure of the data in the file. This meant that the program no longer required advance knowledge of the data structure, but rather could ask the data file how it was structured. Note that there are several variations on the .dbf file structure, and not all dBase-related products and .dbf file structures are necessarily compatible.
A second filetype is the .dbt file format for memo fields. While character fields are limited to 254 characters each, a memo field is a 10-byte pointer into a .dbt file which can include a much larger text field. dBase was very limited in its ability to process memo fields, but some other xBase languages such as Clipper treat memo fields as strings just like character fields for all purposes except permanent storage.
dBase uses .ndx files for indexes. Some xBase languages include compatibility with .ndx files while others use different file formats such as .ntx used by Clipper and .idx/.cdx used by FoxPro.