Ashton-Tate’s dBASE Mac
By Greg Raven
MacDigest
Volume vol. 5 no. 12 (December 1987), page 11
In the lobby of the Ashton-Tate building in Torrance they have created a display in the shape of a pyramid that is built of empty dBASE Mac cartons. After months of waiting for dBASE Mac to be released, it turns out that this display is not only appropriate, it is also the highest (and best) use for this product.
This is not to say that dBASE Mac doesn’t have a ton of bells and whistles. After leading the MS-DOS world in data base sales for years, Ashton-Tate has developed a pretty good idea about what should go into a data base manager.
But if you are looking for speed, using dBASE Mac will give you a feeling somewhat akin to being trapped in amber. Yes, things do happen, but they happen so slowly you may find yourself reaching for the reset button, as I did several times. After a point, you see, it really doesn’t matter if the delay is caused by a system crash or if it is only that the program is languidly dawdling along, marching to its own dormant drummer; you simply want out.
I originally picked up dBASE Mac on the strength of the advertised claim that it makes use of MS-DOS dBASE II and dBASE III files. Unfortunately, it doesn’t work quite the way you might expect. Instead of importing the data from “foreign” files and converting them to dBASE Mac’s internal format, dBASE Mac leaves the files in their original format and creates a separate structure file. This structure file stands between dBASE Mac and the data file, acting as a file librarian so that dBASE Mac knows where to look for records and fields.
My initial benchmarks were conducted on just such a file. DBASE Mac was taking so long to perform each task that I assumed it was because of the “foreign” nature of the files I was using.
Wrong.
Ashton-Tate supplies two applications with dBASE Mac. The first is a complete system as might be used by a video rental store. The second is the traditional checkbook management program. Having used a computer to help balance my checkbook for nearly five years now, I feel safe in saying that about the only thing that would make me go back to manually balancing my checkbook would be having dBASE Mac as the only other alternative. As for the video store application, customers would have time to view the movie and return the tape in the time it took dBASE Mac to update records.
In case you are wondering how slow slow really is, InfoWorld also ran some timings on dBASE Mac and found that relative to McMax (reviewed in the last issue of MacDigest), dBASE Mac took anywhere from eight to 102 times longer to complete the same task. For one task, appending records, the ratio was 59:1, meaning dBASE Mac took nearly one minute to do what McMax did in one second. As pointed out last month, McMax is far from the perfect database, but it is boggling to consider that one of the reasons Ashton-Tate withheld dBASE Mac from the market so long was to improve the speed! As it stands now it is not inconceivable that a Timex Sinclair with a cassette tape running BASIC out of 4k of memory would out-perform dBASE Mac. More boggling still is that even at this leisurely rate, dBASE Mac outperformed 4th Dimension in most areas.
Okay, so it doesn’t internalize foreign files, and its speed is best described in terms normally reserved for geological phenomena. At least it allows you to make use of the hundreds of thousands of lines of existing dBASE III code, right?
Nope.
In their infinite wisdom, Ashton-Tate has apparently decided that the level of compatibility between dBASE Mac and other dBASE products shall extend no further than similarities in the names of the products. Therefore, if you know DOS-style dBASE (or know someone who does) and are looking forward to a quick and shallow learning curve with dBASE Mac, you are going to be disappointed.
After spending a few frustrating hours with dBASE Mac, I called Ashton-Tate support and politely asked if perhaps they didn’t find that the program was a trifle sluggish. I say I asked politely because I took great pains to refrain from using words such as “moribund,” “quiescent,” or “inert.” The support person I talked to replied, “Not really. Of course, we use Mac IIs around here.”
With no run-time package available, dBASE Mac looks to be the perfect choice for businesses that have 1) too much money, 2) Mac IIs, 3) lots of neat things to gossip about throughout the day while dBASE Mac trundles through the mountain of code with which Ashton-Tate has saddled it, and 4) no pressing need to accomplish anything. In other words, it is difficult to conceive of a situation in which dBASE Mac would be the perfect piece of software for the job.
| McMax | McMax run | dBASE Mac | Reflex* | HyperCard | |
|---|---|---|---|---|---|
| Time to open | 8.0 sec | 8.0 sec | 22.1 sec | 8.8 sec | 11.8 sec |
| Time to close | 4.7 sec | 4.7 sec | 7.0 sec | 6.5 sec | 5.5 sec |
| Build file | 20 sec | N/A | (auto) | 20 sec | (auto) |
| Import data | 4.3 sec | 4.3 sec | 10.0 sec** | 60 sec | 1167 sec |
| Sort/index | 15.5 sec | 15.5 sec | 85 sec | (auto) | 52 sec |
| Data file size (bytes) | 60,519 | 60,519 | 51,041 | 74,752 | 287,616 |
| Index file size (bytes) | 45,056 | 45,056 | *** | included | included |
| Program size (bytes) | 260K | 146K | 767K | 202K | 360K |
| Help file size (bytes) | included | user supplied | 85K | 105K | 721K |
All tests performed on a Mac Plus with 2 MB of memory and a SuperMac DataFrame XP20. Memory caching was turned off for all tests.
* Reflex does not have a built-in procedural language.
** For dBASE Mac, “importing” data actually means building the structure file.
*** The size of the original data file (915 records) in dBASE II running under MS-DOS 1.25 is 76,288 bytes with an index file size of 144,384 bytes.
See also: dBASE Mac Revisited (1988)