I worked for Ashton-Tate during the development of dBASE Direct/36 and dBASE IV, using my dBASE III Plus knowledge to code a small program to aid in testing of dBASE Direct/36 (interface to an IBM System/36 Mini Computer). We had to make binary load and call statements to the System/36 SQL tables, which required repetitively typing the same 'load' and 'call' statements while changing the table names and field names upon submission to get the data from the each record or group of several records depending on the scope of the query. dBASE III Plus, a database programming language, allowed me to create, 'dbldot.prg' which changed the single dot prompt to a double dot as I designed to be an indicator that the system was in SQL retrieval mode, as well as the text below the command line that said, "Enter a dBASE Direct/36 Command," replacing "Enter a dBASE III Plus Command," until quitting the dbldot program. The end result was giving the user a means to simply enter SQL statements, as those statements are still used in command line SQL data retrieval today i.e. Select * from... and so on.

Back in that time dBASE was a database programming language, or more accurately, a program language that enabled the manipulation of data records. A record was a group of fields containing data for one individual item, such as a persons LAST_NAME, FIRST_NAME, ADDRESS, CITY, ST, ZIP, PLUS_FOUR, SSN, etc. These structures were later represented in tables and organized into rows and columns, a row being and individual record, and a column being the data in a series of records for each field name. By this way, a user could easily sort by field name to sort and group records by specific common fields, such as CITY, ST, ZIP, etc.

The dBASE language allowed the user or programmer to manipulate data, perform sorts, display tables, records, and perform calculations (Y2K was far off but dates had to be converted to a YYYYMMDD to sort the MM-DD-YYYY data that was entered, which could be done with DtoC and CtoD (Date to Character, Character to Date)). Without the dBASE language, the data files would simply be a series of records (rows) with common fields (columns).

Relational database - that was the term used to cross reference more than one database (table) with another which contained different information but contained one or more common fields. For example, a database titled, "Addresses," contains "LNAME," "FNAME," "ADDRESS," "CITY," "ST," "ZIP," "SSN." Another database titled, "CHECKING," contains "ACCOUNT_NO," "ROUTING_NO," "CUSTLAST," "CUSTFIRST," "DOB," "SSNO," "CUST_NO." Although the field names are different, several of them contain the same information that can be linked to each other to tie the data from one database that that of the other to, say, send out statements to the bank customers, using the first and last name fields and SS numbers to relate the data, pulling the address of the customer from one database and account information to be placed into the statement from the other. Then on a greater scale a mail-merge function can take place to perform these actions on each individual customer in the ADDRESS database, pulling the related account information of each customer, personalizing the statement, printing, and addressing each before moving on to the next record, or customer, in the database.

So, something like MS ACCESS could be more of a DBMS, but on a basic level dBASE was a language to create front-end user interfaces and conduct all of the data manipulation between databases to create a relation between them and return the resulting data for we mere humans to use.

A lot has changed since then, but the foundation remains the same. Data is still contained in records containing a series of fields of various data types and must be cross referenced and merged with that of other databases by way of one or more common data points, allowing us to use credit cards, set up accounts on the web using our Google, Facebook, Twitter IDs, track our purchase histories, and so on. Our lives are just a series of many overlapping relational databases, which we traverse every day without thinking about all the bits and bytes that are interacting to bring us the pleasures and continued evolution of ease in our lives today.

At lease that's how I've always understood it these many years of software and hardware testing which began with dBASE II back in 1984.