DataFlex is a relational database management system, self-described as an applications development database, originated around 1980.
DataFlex is a relational, 4GL Object Oriented database programming language. This means that it has the following features for database engineers:
- relational means the tables can be automatically linked together in meaningful ways. An invoice, for example, can be defined with a header table for the top part of the invoice, and by a details table for the individual line items on the invoice.
- 4GL is a technical description of the language. 4GL stands for fourth generation language. DataFlex uses higher level constructs (syntax and keywords) than 3GL languages. Examples of 3GL languages are C and Fortran.
- Object Oriented (also known as OOP) describes a language that has the ability to represent concepts using classes and objects. Classes encourage the concept of code reuse, whereby the business rules for a module are used in other, related modules. Objects encapsulate sections of the application so that changes in one area do not affect the features and functionality in other areas of the application. Languages that are OOP are generally more powerful than languages that don't have these capabilities.
- database programming language is a phrase used for computer languages that allow the coder to easily interface with a database. Every database has the same types of concepts: table creation, row insertion and updating, row deletion and data lookup. A database programming language simplifies these concepts by providing features that automatically perform the mundane drudgery of moving data around and validating its correctness.
DataFlex is a language that was created by Data Access Corporation around 1978. One of DataFlex's strongest features back then (and now) was its ability to be ported to just about any operating system. Consider, in 1978, that Windows, MS-Dos and even Apple didn't exist yet. CP/M and Unix were the two most common operating systems.
The DataFlex application framework provides developers with a powerful, consistent yet flexible structure in which to maintain and evolve their solutions as user demands and new technologies drive the need for change. The rich, object oriented language gives developers the control to implement almost any database application they can conceive.
DataFlex has a multi-tiered architecture. An application’s business logic is contained in Data Dictionaries and Business Process Objects that are independent of the user interface. This carefully crafted structure provides a common layer of components used to build both Windows and Web application user interfaces.
Developers choose DataFlex because its architecture, application framework, wizards, code generators, rich language and class library mean writing less code and managing less complexity to build and deploy solutions in whatever environment meets the needs of the business: the Windows desktop, as a web service, in web browsers, on cell phones and handheld PDAs.
DataFlex solutions are database independent. Developers can create and deploy on the embedded database or any of the industry’s top database servers without application changing code. Database independence means lower cost, faster change processes, more flexibility and more scalability as database capacity, security, performance, platform and cost considerations change.
Finally, the common thread of any poll of DataFlex developers and their application users is that they use DataFlex "because it works". DataFlex Studio works efficiently for developers as they build, maintain, change and evolve business solutions. The DataFlex Windows Client Engine works reliably supporting end user solutions in health care, transporation, manufacturing, financial services, insurance, education, construction, agriculture, food service, wholesale distribution, retailing, technology, and the public sector. DataFlex Web Application Servers work securely delivering information across the internet in a vast assortment of enterprises large and small.
Even though DataFlex has been around for over 25 years, all of the file extensions used in the first versions of DataFlex are still used and mean the same thing. The introduction of OOP into the language in the early 1990s added a few more extensions (such as VLD). DataFlex's migration to the Internet in the form of the DataFlex WebApp Server in the late 1990s added a few more extensions too.
This is a list of the file extensions (in alphabetical order) that can exist in a DataFlex application.
|BAD||BAD files are generated by the indexing program (dfindex or dfsort, depending on the runtime version) when a duplicate record or a record with invalid bytes has been detected. A .BAD file contains information about the problem that an administrative utility (dfclean) uses to fix the duplicate or invalid records. Unfortunately, .BAD files are not deleted by dfclean. The existence of a .BAD file indicates that there was a problem at that time. The only way to know for certain that the problem was fixed is to perform a new dfindex (or dfsort) on the datafile.|
|BP||A BP file is the source code for an object that contains logic about a business process. A business process is an algorithm that exists solely to facilitate a step in a transaction. Examples of business processes are tax calculations, minimum inventory threshold calculations, security levels for various user roles, and the selection of the next inventory part to pick in a FIFO queue.|
|BPO||A BPO (business process object) is a synonym for a BP file.|
|CFG|| CFG files are configuration files -- files that define how DataFlex will behave on that installation.
The configuration files typically seen are:
|DAT||DataFlex datafile or table files all have a .DAT extension. Each datafile holds one (and only one) table, so a datafile and table (in DataFlex) are synonymous. Each datafile should have a .TAG and .FD file, and optionally a .HDR, .K* files, and a .VLD file. Because of the way DataFlex runs, .TAG and .FD files are not needed by the DataFlex runtime, so .TAG and .FD files might be missing.|
|DD||A DD (Data Dictionary) is a synonym for a DataFlex Data_Set.|
|DEF||Datafile (table) definitions have a .DEF extension. DEF files are written by the DataFlex file definition program.|
|DFR||DFR files count users and verify that the limits of the DataFlex license have not been exceeded. DFR files are named number.DFR, such as 1234.DFR. The number corresponds with the DataFlex serial number for that installation.|
|DG||A DG files is the source code for a dialog box. A dialog box is a data entry screen that forces a user to either acknowledge or cancel the box before the user is allowed to continue. Examples of dialog boxes are error messages and wizard screens.|
|DS||A DataFlex Data_Set is an object that encapsulates the interface to a DataFlex datafile. All interaction with a DataFlex datafile should ideally occur through a Data Set Object.|
|DSO||A DSO is a synonym for a DS (DataFlex Data_Set).|
|EXE||EXE files are the DataFlex runtime. The runtime can not be decompiled -- only .FLX files can be decompiled. In versions of Visual DataFlex starting with 8.0, EXE files are also DataFlex programs.|
|FD||An FD file contains an association between the real name of a datafile and the internal DataFlex number. For example, the CUSTOMER datafile might be internally associated with the number 15. FD files also contain information about the definition of each column in a DataFlex table. This is used by the DataFlex compiler to associate file and field references in source code with an internal numbering scheme used within the DataFlex runtime.|
|FLX||FLX files are compiled DataFlex programs. The source code for these programs can be restored by using The Database Managers' decompiling service.|
|HDR||An HDR file is a header file for a datafile. If header files exist, there will be one HDR for each DAT. The header file is mostly a copy of the the first 2,776 bytes of the datafile in case that part of the file gets clobbered for some reason (usually due to a hardware related failure, such as power failure). An administrative utility allows a developer to restore a damaged header based on the 'backup' provided in the HDR file. More information about HDR files is available at the Data Access Corporation website.|
|INC||An INC file is a source file that is designed to be included into some other source file. INC files typically define macros and other extraneous and reusable bits of code. An unwritten convention says that INC files can be included multiple times within a source file without causing a compile-time error. This is in direct contrast to a package file that can only be included one time. The difference is that an INC file normally has compiler directives embedded in the source file to guard against causing compile-time errors when it is included twice, whereas a PKG file normally lacks those mechanics. INC files are normally included into source files using the #include compiler directive.|
|K*|| DataFlex index files have a .K* extension. The * of K* is a one or two digit number. Values of K* will range from K1 through K15. In DataFlex 2.x, the K10 index was always a 'batch' index, which means its contents were not updated when the datafile was updated. Batch indexes are only updated when the index is (re)created with dfindex or dfsort, depending on which version of DataFlex you have. This provided some advantages in certain situations, but most of those advantages have become obsolete with the faster computers and larger hard drives we enjoy today.
Index files can sometimes be enormous. I've seen index files that were bigger than the datafile they were indexing! Because index files are so big, and because the dfsort utility in modern versions of DataFlex is so fast, it's oftentimes not necessary to back up index files. The reason is that in those rare circumstances when a datafile is restored from a backup, it takes little time to reindex all of the datafiles for a small or medium-sized application. The time saved by not having to back up index files every day outweighs the time wasted reindexing a restored datafile.
Also, depending on your backup medium, it can be faster to simply reindex a datafile versus restoring the file from the backup medium.
|MAC||A MAC file is a source file that contains DataFlex macro definitions. See also INC files.|
|PIF||A PIF file is a Windows Program Information File used by Windows to determine how to run the DataFlex application.|
|PKG||A PKG file normally contains class and object definitions. Because of that, a PKG file should normally be compiled into a DataFlex program one time. The USE command guards against compiling a PKG file twice into the same program. A PKG file is in direct contrast to an INC file, which is assumed to be included into a source file more than one time.|
|PRN||In 2.x versions of DataFlex, PRN files are graphic device drivers. PRN files can also be debugging output from the compiler.|
|RV||A report view contains the class and object definitions for a specific report.|
|SL||A selection list is an object that allows a user to choose one or more records from a scrollable list of records.|
|SRC||An SRC file is a DataFlex source file.|
|TAG||Similar to an FD file, a TAG file is an ASCII file that contains a line delimited list of the fields defined in a table. It used used by DFQuery to let the user choose the fields from a datafile.|
|VLD||In DataFlex 3.0, the variable length datafile, or VLD file, was introduced. When VLD files are used, the VLD file holds the real data and the DAT file simply holds a pointer to the location in the VLD file where the data resides. Therefore, when backing up or restoring a datafile, it's vitally important that the DAT and VLD (and HDR) be kept in synchronization with each other. A VLD file without a DAT file is completely useless, just like an index file (K*) would be without its DAT file.|
|VW||A view is a data entry panel.|
|WBO||A Web Business Object is a synonym for a WO file.|
|WO||A Web Object provides an interface between the ASP code and the Data Sets and Business Objects.|
DataFlex is a highly portable database language. It is able to run programs, without being recompiled, across Windows and Unix platforms. Likewise, the end-user terminals that DataFlex runs on is as diverse as WYSE-50 terminals and PC workstations.
Unfortunately for non-DataFlex programmers, there is not a univeral standard for the information that a workstation sends to the computer. For example, the when a user hits the 'Control+A' key on a VT100 workstation, it sends a different set of codes to the computer than on a PC workstation.
Historically, non-DataFlex programmers have had to create a terminal definition for each different type of hardware that they want their programs to be used on. The terminal definition describes, for a particular type of terminal, the codes that the computer receives when various key combinations are pressed.
A terminal definition acts as a Rosetta Stone by allowing a program to detect which key or combination of keys was pressed by the user. The programmer doesn't need to write different programs for each type of terminal.
Data Access Corporation (DAC) chose to do things differently for their DataFlex database management product. DataFlex eliminates the need for a programmer to create a terminal definition. Each terminal type that DataFlex can run on has a terminal definition already built into DataFlex.
To accomodate such a diverse range of hardware, DAC has created the concept of a Flexkey. DataFlex Flexkeys are general data entry and database concepts, such as:
- Save a Record
- Delete a Record
- Find a Record
- Clear all Windows
- Print Screen
- plus others...
Every Flexkey, such as Save, is assigned a specific keystroke on each type of terminal. The default Flexkey definitions provided by DAC all use the same keystrokes for all workstations. Because of this, in DataFlex 2.3, the default definition for the Save Flexkey is the F10 key for all workstations.
DataFlex administrators can reassign Flexkeys for a particular type of workstation. This means that all of the PC workstations can use a non-standard keystroke to represent a particular Flexkey. For example, Control+S could be defined to mean the Save Flexkey, and Control+K (for kill record) could mean the Delete Flexkey.
Some developers adopted the default definitions for all of the Flexkeys; other developers tried to make mnemonic associations for the Flexkeys.
My experience with key mapping is that it largely depended on what the users wanted -- if they wanted mnemonic associations, I installed it that way. If they wanted to use the standard keymap, then I installed it that way.
Compiling DataFlex Programs
The DataFlex compiler, dfcomp, normally displays compile-time errors directly on the screen. For example, when the program being compiled is
// prog.src: // This program has 3 compile-time errors. integer i for i from 1 to 10 showlnx i // should be showln loop string akey 1 inkey ackey // should be a key
and the compiler is executed as
the DataFlex compiler reports
DataFlex Compiler, V3.1d Copyright 1981-1998 Data Access Corporation Miami FL, USA - All Rights Reserved Compiling Program: prog.src showlnx i // should be showln ERROR: 164 COMMAND NOT FOUND: SHOWLNX ON LINE: 7 (7) OF FILE: prog.src Do you want to abort the compiler (Y or N) _
on the screen. For single programs, this is acceptable because the compiler immediately tells you when it encountered a problem.
Sometimes, however, an entire project needs to be completely recompiled. Unfortunately, the DataFlex dfcomp compiler doesn't allow us to use:
Even if it were possible, it would be inconvenient to have to baby-sit the compilation. Each error encountered during compilation will stop the dfcomp compiler and it will wait for the programmer to acknowledge the error message.
On Windows, the FOR command can be used to process a group of files. The syntax to use on the command line is
for %s in (*.src) do dfcomp %s
If the above command is put into a batch file, then each of the % signs needs to be doubled, like this:
dfc.bat: for %%s in (*.src) do dfcomp %%s
This is a convenient batch file but it's restricted (hard-coded) to a specific set of source files (*.SRC). For example, let's say my Accounts Payable programs start with AP* and my General Ledger programs start with GL*. I could have two batch files that compile each group: DFC_AP.BAT would compile all of my AP*.SRC files and DFC_GL.BAT would compile the General Ledger files.
The DFC_AP.BAT file would look something like:
for %%s in (AP*.src) do dfcomp %%s
and the DFC_GL.BAT file would look something like:
for %%s in (GL*.src) do dfcomp %%s