dBASE IV - a sneak preview
By John Pochodowicz

I recently attended the Ashton-Tate developers' conference on dBASE IV. Ed Esber, Chairman and CEO of Ashton-Tate, kicked off the conference by confessing that Ashton-Tate had sinned by failing to listen to the developer community. As a result, the developers generally moved their programming efforts to Quicksilver, Clipper and Foxbase+. Programmers abandoned dBASE III Plus because the clone makers added powerful improvements to the dBASE language. Esber apologized, adding that things would be different. The audience, although skeptical, listened and waited patiently to see what Ashton-Tate would really do.

Ashton-Tate announced dBASE IV, on February 17, 1988, with release anticipated for July. After numerous delays, shipment started on October 24, 1988. For this article, I based most of my observations on a pre-release version. If you think the delay allowed Ashton-Tate time enough to eliminate all the bugs, you'll be disappointed.

The expressed dBASE IV goals are increased speed, ease of use, a connectivity foundation, a language compiler and 100 percent compatibility with dBASE III. While Ashton-Tate may strive for these goals, the first dBASE IIl PLUS program I executed in dBASE IV failed the compatibility test. Let me share a few observations from a program developer's viewpoint with you.

Applications Generator The Applications Generator allows several levels of program generation, from the beginner level using "generate quick application" to the professional level with a fully modifiable template language. The applications generator allows bar menus, pull-downs, pop-ups and pick-lists. The new menu editor is a "wysiwyg" type which can support up to 32,000 line programs. In a direct quote from the pre-release documentation: "The Applications Generator is an easy-to-use tool for building both simple and complex applications." I tried to build an application of medium complexity but couldn't get my custom generation efforts to run. I admit to spending less than four hours trying, but I should have been successful at using more than just the generate quick application. I assume I'll have greater success with the production version. When you get your package, build the sample application provided in the book before getting creative.

Control Center The new control center replaces the Assistant function, making the system more useful for the novice and of some value to a developer working in the interactive mode. A 200-page book describes the features of this easy to use menu system/control center.

Debugger The pre-release literature indicates that the full screen debugger is only available with the developer's version. I was disappointed since even a novice can benefit from such a tool. I understood the need for Ashton-Tate to have a few things of value in the developer's release, other than the yet-to-be-released professional compiler and the template language compiler, so I accepted their position. When I received my copy of dBASE IV version 1, I verified that the debugger had been excluded. Then I entered "DEBUG TESTl" to re-execute some of the routines I had used to test the debugger under the pre-release version. I was surprised to find that the debugger, in fact, had been included. Did someone slip up or did Ashton-Tate have a change of heart?

The debugger screen has four windows letting you run a program or procedure and see the commands as the program code is executing, edit the program or procedure, set breakpoints to halt program execution when one of up to 10 conditions is encountered and display the results of up to 10 expressions while the program is executing. The breakpoint and display windows accommodate statements/expressions up to 100 positions long, using a sliding window of 24 positions for entering information.

As far as I am concerned, having access to a debugger in dBASE IV constitutes sufficient reason for serious dBASE III PLUS developers to upgrade, even if they don't use any of the new command language features.

Documentation dBASE IV comes in a heavy box, containing a three ring binder with fourteen 5 l/4-inch disks or eight 3 1/2-inch disks, a three-ring binder containing the language reference and an angle box labeled "Using dBASE IV." The books and booklets in the box are bound. You must annotate the changes in the materials or Ashton-Tate must produce replacement books rather than replacement pages. A sheet included with the package lists several important amendments that already must be made to these books. The language reference is a vast improvement over previous versions. I like having a well-indexed, alphabetized language reference containing commands, functions, system memory variables, and system configuration information.

File Extensions dBASE IV uses many new two or three letter file extensions following the period in the file name. I counted 61 different extensions. While only 20 to 30 will be encountered in the normal course of building an application, even this number requires extraordinary disk management , or the DOS directory structure will be flooded with files and disk access will be sluggish. Ashton-Tate recommends a config.sys file with a buffers=4O statement, obviously in anticipation of many open files during normal system creation and/or execution.

Indexes dBASE IV uses a new method of indexing that has the capability of maintaining up to 47 index tags in a single file called an .mdx (multiple index) file. Each index tag is similar to an old .ndx file. Every time a .dbf is used, the associated .mdx file is opened and each index tag automatically updates when index key information changes in the database file.

If the application is currently using .ndx files, an "N" answer to the index prompt associated with each field on the CREATE or MODIFY STRUCTURE screens will prevent .mdx file creation. If "Y" is entered for any response to the index prompt, the .mdx will automatically be created, duplicating the .ndx files.

Curious to evaluate the efficiency of the new .mdx files, I ran a test to compare the size of the .mdx with five .ndx files. The .mdx was smaller and is automatically updated so the .mdx appears to be an advantage over individual .ndx files. I discovered that deleting a tag from the .mdx does not reduce its size, and adding the same tag back into the .mdx further increases the size of the .mdx. Use .mdx for new application development cautiously until the concept matures.

Memo Fields Many new commands and functions are available for memo field processing. The change summary documentation indicates that disk use with regard to memo fields has been vastly improved over previous dBASE versions. Instead of wasting space occupied by outdated memo field information, dBASE IV recycles this old space, resulting in significantly smaller .dbt files. The change sheet , included along with the disks, hints at continuing problems with the .dbt files. The change sheet says: ÒWhen removing deleted records from a database file that contains memo fields, use the COPY TO command (rather than PACK) to create a new file for optimum performance. The new file will not contain the records marked for deletion. Delete the old .dbf and .dbt files and rename the new .dbf and .dbt files with the old names. If there is an associated .mdx file, put the new .dbf in USE after renaming it and issue a REINDEX command. Maybe .dbt files are not as improved as Ashton-Tate would like us to believe.

Networking The new version of dBASE IV offers several levels of network-locking security: automatic file locking, automatic record locking, explicit file locking and explicit record locking. In prior versions of dBASE, corruption of the database and/or index might occur if two users attempted to update the same record at the same time, unless the programmer issued file and/or record locks at the appropriate times depending on the action desired by the user. dBASE IV offers several levels of automatic protections to the interactive user and the programmer, dBASE IV automatically attempts to lock a file or record when the user executes any command that modifies a file or record. When using the CHANGE, EDIT or BROWSE commands, dBASE IV delays the attempt to lock the record until input that updates a record is entered, that is, when the user presses a key that changes the record. Automatic locking ensures that each file or record changed is guarded from change by other network users while the update progresses. Automatic file and record locking means eliminating the necessity for issuing an explicit lock or unlock of the file or record that is being updated. If another network user has previously locked the needed file or record, the system displays a prompt box and the user can retry or abort the lock attempt. The SET REPROCESS command allows the user to specify the number of times the system will attempt to lock the record or file before the system issues the prompt box calling for retry or abort. Users should know that dBASE IV automatically locks index and other related dBASE files. With automatic record locking, single-user applications move more easily to a multi-user environment. Using memory variables to update the fields in the database, instead of making the changes directly into the record, increases the possibility of losing the first user's update if two users access and modify the same record.

dBASE IV has several new LAN oriented commands, such as CONVERT which adds a field called dbaselock to the structure of the active database file to allow for automatic change detection for commands like BROWSE and EDIT.

dBASE IV provides a transaction processing capability that creates a transaction log file of all changes to all the related database files, from the start of the transaction until an END TRANSACTION command is issued. If an error occurs between the START TRANSACTION and the END TRANSACTION commands, the portion of the transaction that had been completed prior to the error can be reversed using the ROLLBACK command. All database files will then be left in their original state. Once the END TRANSACTION command completes successfully, the transaction log file is purged and all the locks associated with the transaction are released. All file and record locks created in a transaction remain in effect until dBASE IV encounters the END TRANSACTION or ROLLBACK command. The UNLOCK command has no effect within a transaction. A transaction, therefore, should not cover an extended length of time because all locked files and records will not be accessible to other users until the END TRANSACTION command has been issued.

The network installation book indicates that dBASE IV will operate with only four network software packages. If the user doesn't have either IBM PC LAN Program - version 1.2 or later, including TOKEN-Ring; NOVELL SFT Netware 286 with TTS version 2.1; Ungermann-Bass NET/One PC System - version 15.2; or 3COM 3+ Share Software - version 1.2, then an upgrade to the latest version will be necessary.

Reports The new report writer creates modifiable code and is significantly more powerful than the the old CREATE REPORT command in dBASE III PLUS. dBASE IV now supports the use of optional, installable printer drivers to control print functions.

Structured Query Language SQL, an advanced relational database query language has been implemented. SQL operates on data entirely as logical sets called relations (tables), providing a small and concise set of commands that allow the user to define, display and update information in the tables. I tried this in the interactive mode and was unimpressed. Every statement takes too much time executing. I assume the SQL processor translates each statement back to dBASE before the other command executes. I'll wait until I have mastered the other features before trying SQL again.

The development effort that went into dBASE IV must have been staggering. The most significant efforts are the inclusion of Foxbase+, Clipper and Quicksilver pioneered commands and functions. The template application development language, originally introduced by several independent software developers, is a welcome addition. Ashton-Tate's initial attempt to integrate SQL into the dBASE language will start to address the micro to mini/mainframe connectivity issue. The potential block-buster combination for the program development community is the full-screen debugger and the yet-to-be-released professional optimizing compiler. As a developer, I consider dBASE IV too new for implementation in the department as the applications software development product of choice. I'll give dBASE IV serious consideration when version 1.1 and/or the professional optimizing compiler are released.

I would like other dBASE IV pioneers to write articles for Chips giving detailed information on the new commands and functions and tips for the efficient use of this product. Let me get things started with tip number one. Once the license agreement is memorized and the sign-on graphics are no longer cute, relief may be obtained by entering "dbase/t" from the DOS prompt.

Summary of Changes Support for extensive windowing Keyboard macros permitting creation and replay of keystrokes Query-by-Example Structured Query Language Increased number of fields up to 255 Support for multiple-child, multiple-file relationships Support for DOS read-only file attribute Support for commands and functions operating on unselected work areas Increased command line length of 1,024 characters Support for financial, statistical, math and trig functions Increased support for memo fields Support for fixed and floating point numbers Support for arrays of memory variables Increased memory variable limits up to 15,000 Immediate updating of disk files using AUTOSAVE Improved screen painter, help system and protect utility Support for user defined functions Support for 963 procedures per file (vice 32 in dBASE III Plus)

About the Author: Pochodowicz is Head of the Data Processing Programming Support Department at NARDAC San Diego. His phone number is (619) 437-7527.