Review of Filemaker 3.0 (İ Kevin Jaques 1996)

İ(c)1995 Kevin Jaques. All rights reserved excepting that this file may be copied for non-commercial purposes, unchanged. No warranties apply. I am just a user volunteering my observations.

I have used Filemaker since I opened my office in 1988. However, I have lusted for a good relational database. A word of explanation. A field contains data of a particular type (e.g., date, string, number, integer). A Œrecordı contains a designated group of fields. A ıfileı contains a list of records, all of the same structure. A Œfileı was normally also the disk file by which it was known by the Finder. A Œlayoutı is how the data is displayed. A Œrelationalı database permits you to connect files of different types (e.g., people to addresses) by matching them on some criteria. Usually that criteria is that a field from each is designated as a Œkey fieldı, which makes the connection whenever it exactly matches the Œkey fieldı from the other file.

I previously presented a review of the main contenders in that field, in 1993 or 4. At that time, there was 4D, about $3,000, FoxBase, about $300, Helix, about $700, and Omnsis, about $3,000. Helix had a graphical interface, an incomprehensible manual, and was totally non­extendable. FoxBase was a souped up version of dbase III, very popular in the pc world, very fast, but almost totally non­mac­like. Every thing about it had to be written in command­line code, although it had great macros to help you write it. 4D was extremely powerful. Both Foxbase and 4D permitted extension via the installation of XCMD and XFCN resources.

FoxBase had been recently acquired by Microsoft. It was available on Macs or pcs, and could network with the other type. It stored a separate file for everything on disk, from indexes, to layouts, to data, to print layouts. You see, a print layout could not be used for input. Only 10 files could be open at once, but you could set up collections (I forget their term) to facillitate the opening of particular combinations.

4D and Helix stored all the data from all the Œfilesı (i.e., collections of data in like­structured records) in a single file. That turned out to be disastrously bad. My powerbook has no need for all the billing information, but you canıt take copies of just those you like.

None of them compared to the use of use of Filemaker. When you make a layout, you can print or enter to it. When you view records in a list, you can still enter. When you say that a field will be the product of a calculation, then it fixes the calculation when relevant data changes. When you print, the Œsummariesı or Œbreaksı are easy to control and flexible. But Filemaker was just a flat­file, non­relational database.

4D and Foxbase permitted you to distribute Œrun­timeı programs, so that non­registered users could run your databases. Both also permitted you to Œcompileı a database as a stand­alone program. 4D, of course, charged extra, a lot extra, for that.

I felt it came down to 4D and FoxBase. FoxBase was just too tricky to program. You even had to make sure that your indices got updated when data was changed. 4D was too expensive, but I had a trial copy, and I figured that by the time I was ready to implement it, prices would have fallen, so I chose 4D as the best of a bad lot.

Since then, cool things have come out like Phyla (objected oriented but not programmable or even scriptable), and almost relational PIMs (Personal Information Managers).

By 1996, I was just preparing my data for import to 4D. It had taken a long time and a lot of work to get something working that I liked. My problem is that I require accomodation of true many­to­many relations. For instance, several people might be involved in a project, but those people might be involved in several projects, none of which might have the same combination of people.

Just then, Filemaker 3.0 came out. At that time, FoxBase was included in Microsoft office for next to nothing. But Word 6.0 was unworkably slow, and besides, I canıt buy from Microsoft any more. 4D had a version out for about $300, but to make it work on a network or to share files, you had to pony up another $1700. Filemaker 3.0 is now relational. It cost me $139, and it is networkable! You canıt beat that.

Not only is it relational, shareable, and cheap, Filemaker 3.0 is AppleScript savvy, being both scriptable and recordable. It has lost none of its ease of use.

Further, it comes with a database which has an excellent description of Apple Events in general, things like names, ids, parameters. The database has fabulous tables and maps and lists of the AEs that Filemaker 3.0 supports. It also comes with many examples of scripts to control Filemaker. It also comes with queer gaps in what it can do, so scripting becomes more essential.

It took me a solid week to implement a system in Filemaker. I now have files for Businesses, Accounts, Invoices, Rates, TimeAndDisbursements, Entities, Phones, Addresses, and Network. Businesses have a record for each business that I am running to contain letterheads, fee structures, and things like Œnext invoice numberı.  Accounts are related to the Business, and linked to those entities which are liable to pay, and contains things like last statement date, balance owing, etc. Invoices are related to the Account, and contain things like total fees, total disbursements, total GST, total adjustments, and total. TimeDisbursements are related to Invoices and contain things like date, item, units, and so forth. It looks up rate and GST taxability of the item from Rates.

A solid week compares well to 3 years of work. That demonstrates a certain ease of use.

It is just plain sweet to use. Although this article is intended to be a ringing endorsement, I canıt elaborate much more on that, but will now turn to problems.

Of the fatal variety is its inability to install a script to be handled upon an event, like HyperCard can do. Oh! If only HyperCard was indexed and had layouts! You can install a script to be done when a file is opened or closed, or upon a button click. Thatıs it. So, forget about updating summaries. That would be less horrible if its summaries were Œsmartı. In a spreadsheet, when a cell contains a summary, then when a cell included in that summary is changed, then the summary is adjusted, not recalculated! However, in Filemaker, it is recalculated every time. So, if you hope to display dynamic totals, you better not involve more than a few hundred records.

It is bad, in that you canıt designate any other type of matching criteria than Œexact matchı from one field to one other field.

It claims to offer Œmany to manyı relationships. In a sense this is true. It is wonderful in that it can maintain multiple relations between the same two files. For instance, a single entity could be linked to several phone numbers, provided there was a separate key field for each one. Of course several entities could be linked to the same phone in this way. However, this is not a Œtrueı ımany to manyı relationship, because you do not have a flexible number of related records. You must set up a key field for each.

I got around the Œmany to manyı restriction but setting up an intermediary file called Links. It contains 2 key fields, one from the first file, and one from the second. Then entities can use its own record number to link to any number of link records, each of which will be related to one record from the second file. If you are in Phones, then its record number relates to any number of links, each of which are similarly related to a single record in another file. This is a true Œmany to manyı relationship. I canıt imagine why it isnıt built in. There are many difficulties in implementing it. For one, you must check whether a key field relates to either side of the link record. In FileMaker, since the matching criteria is so limited, that means you must set up two separate relations. So forget about sorting or finding.

Speaking of sorting or finding, you canıt seem to control the order in which the related records appear.

You still canıt make a function which will take parameters, or even a command. You canıt call a script from a calculation. You canıt call a calculation from a script. At least you can make and call an AppleScript handler in another application from a script, though not from a calculation.

In designing your layouts, you can put a fields contents into a text box, as a Œmergeı field, to make formatting easier. Further, you can now fully format, even with tabs and line formatting, the contents of fields. I got so excited. I thought I had finally found my document assembler! But you canıt put Œmerge fieldsı into the data of a text field, just into the contents of a text box. Bummer.

Oddly, you canıt underline a tab.

Oddly, you canıt store booleans, though you can format numbers to seem like them. What a waste of space!

Speaking of space, the program is actually smaller than the last version, perhaps because you choose whether to install the 68K version or the PPC version. Since you can now elect to not index, or even not store, the results of calculations, the data files are smaller. The introduction of global fields is welcome, and further reduces file size, but bewareŠ if a calculation uses a global file, it canıt be indexed!

It searches rapidly, with an index, based on related fields. Layouts continue to be sweet to design.

The scripting is intolerable, because you canıt copy and paste! So, if you have many files (like me) and you need the same simple script in each, it makes you briefly hate Claris. You can duplicate, but that only helps if you need a similar script in the same file.

You have had the option of popuplists, popup menus, radio buttons and check boxes for a long time. But now, you can  store the value lists separately, to be accessible by more than one field (e.g., type of address could be Œmail, residence, work, current locationı etc. They can even be dynamicŠ partly. You can set them to be the contents of a designated field. Actually, that means that you get a list, based on the contents of that field, from the Œfound setı of that file. That is excellent, but only a partial answer.

Another fatal failure is network speed. I have a Power 100 using AppleTalk over Ethernet cables to a IIci. The speed is quite satisfactory on the Power 100 (excepting summaries of over a few hundred records), but when using it as a guest, it is intolerably slow! I guess they want you to buy their server version, which goes for about $1700. Bastards! Recall that the winning factor for Filemaker was the low price of a networkable database. It was just a trick. It is possible, though no better, that they wrote it for the PPC machines, and the version for the 68K machines is just cobbled together (sort of like Word 6.0ıs Mac version).

In short, buy it. Use it. But it wonıt be the whole answer until scripts and calculations are integrated, and until you can install a script or calculation upon a particular event. And until they speed up the network.

Filemaker comes from Claris, at www.claris.com.


This Review of Filemaker 3.0 was delivered by:


			Kevin Jaques, B.A. LL.B.
										of the
							Jaques Law Office

#101 - 2515 Victoria Avenue			Fax: 525­4173
Regina, Saskatchewan									Home: 586­2234
email: jaques.law@dlcwest.com		Tel: 359­3041
visit our web page at http://www.dlcwest.com/~jaques.law/