Volume Number: 16 (2000)
Issue Number: 2
Column Tag: Tools of the Trade

FileMaker Pro 5

by William Porter, Polytrope Solutions, Houston, Texas

Is better good enough?

FileMaker Pro 4.x, released in 1997, was a wonderful product, my favorite application, packing a fair amount of power into a tool with the best GUI known to man or geek. FileMaker Pro 5, released in October 1999, is better than FileMaker Pro 4. So a fortiori, FileMaker 5 must be even more wonderful, right? It depends.

End-users and what I might call pro se developers have always been FileMaker's primary market, because the product has had a winning combination of power and ease of use. That does not change in version 5, and these users, who were already pretty happy with FileMaker 4, will enjoy the enhancements in version 5. Small-time web publishers will find instant web publishing with FileMaker 5 even easier than before and a little more secure.

On the other hand, professional developers, who have been hoping for years that FileMaker would one day release an upgrade that would take the program to the next level the way the version 3 upgrade did, are bound to be ambivalent at best about version 5. Some will be downright disappointed. FileMaker 5's single most interesting feature (XML support) is too much, too soon (and you will need the Developer Edition to take advantage of it anyway). In other ways, 5's improvements seem like too little, too late.

This review is addressed mainly to professional developers, those who are developing or hope to be developing solutions, especially complex solutions, for paying clients. Please note that the review deals exclusively with the FileMaker Pro 5 Standard Edition. Neither FileMaker Pro Unlimited (for web deployment) nor FileMaker Pro Developer Edition have been released yet. But according to the advance information from FileMaker, Inc. (FMI), FileMaker Pro 5 Unlimited differs from the Standard Edition mainly in that it does not count the number of IP addresses accessing the databases. (Unlimited's license is also slightly different and allows you to use it with third-party CGIs like Lasso, but that is apparently not a technical difference.) And advance publicity about the Developer Edition indicates that it will not address any of the problems I discuss here. (In addition to giving developers the ability to build single-user runtime versions of their solutions - useful mainly for demos - the Developer Edition mainly provides the APIs needed to develop plug-ins for FileMaker Pro 5. But the copy of FileMaker Pro 5 that comes with FileMaker Pro Developer Edition is no different from the copy under review here - same development environment, same plusses and minuses.)

For many years, developers have complained that FileMaker's development dialogs - in particular, those for defining fields, relationships, calculations, and scripts - were too small. Every developer I know had hacked his copy of FileMaker with ResEdit to make the dialogs larger. So it was not surprising that the audience at the FileMaker Developers Conference in San Diego last August cheered enthusiastically when it was pointed out with a flourish that the dialogs in FileMaker 5 are finally resizable. FileMaker has been listening to us! we thought.

The cheers might have turned to groans had FMI also pointed out that the dialogs do not stay resized. You have to resize them every time you open them. FileMaker was listening, but with only one ear. Admittedly, this is a small thing. But it seems oddly typical of the entire upgrade, so many aspects of which leave one wondering why they didn't go the extra block and a half and really do it right.

(Not much can be done about the calculation-definition dialog, but you can reduce the frustration of having to resize the other dialogs every time you open them by creating a macro in KeyQuencer or QuicKeys to do it for you. Every time I open a resizable dialog now, I type control-Z, and KeyQuencer zooms it for me to full size.)

There are indeed some very satisfactory improvements in FileMaker 5, such as relational (or conditional) value lists. A relational value list is nothing more than a relationship that has been defined specifically for use as a value list. (Since its a real relationship, you can make use of it in a portal as well, but you probably won't.) Its most obvious use is to provide different options for different items, for example, a flannel shirt might come in red and green and four different sizes, while a pair of shoes might come in black and brown and fifteen different sizes.

The figure shows values in the "option" field that come from another file. The relationship is based on a match between product ID in the current file and product ID in the options file. In the figure, the user is viewing the options for the propeller cap product. The list of options shown here is peculiar to the product "propeller cap." If you clicked on the record for the Bach tee shirt, the list would show the options "J.C., J.S., P.D.Q. and W.F." These values are drawn from records in the Options file. If you wanted to have more than one relational value list, you would simply create more than one options file. (A clothing store might allow customers to select size and color.)

I have one complaint about this feature. It is hard to get these options to sort the way you would like. I wanted a set of size options to sort as S, M, L and XL, but they always appeared in the list as L, M, S and XL (alphabetical order). Normal value lists can use a custom order. Frankly, I was surprised that the values did not display in the order they were entered in the options file. Still, it's a nice feature.

The most interesting change to FileMaker's GUI in version 5 is the addition of a tabular display of data. In table view, all the fields displayed on the layout for a record are displayed in a single row, although you don't lose all of the text and number formats assigned to fields. (In the screen shot below, notice the dollar-signs in the price and the bold product names.)

The options for table view are set in the layout setup dialog. You can allow users to resize columns or even drag them around. In the figure, the user has just sorted the product ID field by clicking on it. I like this addition a lot, because it has allowed me to create a layout that users can safely play with, if they want to create their own simple reports.

This feature is not without its problems. If you are going to use table view, you will probably want to give your fields plain English names rather than employ the special field-naming conventions many developers favor ("cn_statetax" for a numeric calculation field, for example), since the column titles in table view display the real names of the fields and cannot be changed. Second, if you wish to offer your user a list view that you have designed and also a table view, you will probably want to create two different layouts and place a button on them that toggles the views back and forth. This is the only way to get column/field titles to appear once and only once in each view. In the figure above, note that the field titles in bold are placed on the header part and continue to appear even though in table view, the columns are automatically titled. If you remove the field titles from the header part, the table view will look better - but when the user switches back to normal list view, the fields will be without titles of any sort. The only good solution is to use two layouts.

Finally, when I created a table layout using my own column titles (because I didn't want users to resize columns), I discovered something very odd: You can control the appearance of the table columns while in Browse mode, but you cannot control the look of the columns in layout mode. I had a lot of trouble getting my column titles (text objects placed on a header part) to align properly with the table columns. I had to keep switching back and forth between browse and layout modes to see how things were lining up.

An "improvement" I find less useful, but which others will no doubt appreciate, is the addition of two toolbars, one for standard FileMaker commands like sort and find and omit, the other for text formatting. FileMaker 5 is making a play to replace Access as the preferred database for Office users under Windows, and these toolbars have been designed to look as Microsoft-like as possible.

Last but not least among the little blessings is the inclusion of a special import routine for updating one file with data from a copy (e.g., updating a master contacts database stored on a file server from recent data stored in the contacts database on a PowerBook). You specify one or more match fields, then define which of the other fields you want to import.

Perhaps it is because I am a Lasso developer that I am unimpressed by the improvements in FileMaker 5's web-publishing tools. Or perhaps it is because they are just not as good as they sound at first.

The bad news here is that, if you are using the Standard Edition to publish your data on a TCP/IP network (internet or intranet), the host copy of FileMaker will accept remote connections from no more than ten IP addresses during a "rolling twelve-hour period." This is a fairly novel way of distinguishing products and I suppose it reflects the difficulty of figuring out how to license web-application software. With FileMaker Pro 4.x and the Web Companion, for about $200 (street price), you could publish a database and users around the world could actually connect to it, view its data, create and edit records, and so on. You did not even have to buy a full web server such as WebSTAR. To do the same thing with FileMaker 5, you'll need to spend five times as much to get FileMaker 5 Unlimited. This has caused a certain amount of complaining among users familiar with FileMaker 4. But these changes in the pricing of the products seem reasonable to me. FMI was giving the goods away before.

Nevertheless, the limitation in the Standard Edition is so severe that it is a little hard to understand why FMI bothered including any sort of web-capability with the Standard Edition at all. Note that the restriction refers to IP addresses, not users. Unless your expectations are extremely low, this makes Standard Edition more or less useless as a Web-publishing tool. The Web is supposed to be all about connectivity, but web publishing with FileMaker 5 Standard Edition has to be about discouraging connections. A single user with a dialup connection to his ISP might exceed the ten-IP limit all by himself, if he disconnected and connected repeatedly and received a different dynamic IP address each time he reconnected. This is not a far-fetched scenario if the user is, say, a travelling salesman dialing into the home server to place orders. A single user bent on mischief could do the same thing on purpose and lock up a database. Standard Edition's web-publishing ability seems useful mainly on a departmental intranet, where a small number of fellow workers with fixed IP addresses will be able to access a shared database using their browsers, thus eliminating the need to purchase extra copies of FileMaker. It is important to keep these limitations in mind, since FMI's advertising emphasizes FileMaker 5's web-publishing capability.

The good news is that you get to publish your databases using your own layouts - more or less. In other words, you do not need to create web pages in Home Page or GoLive to have a custom look to your pages, and you do not need to write any HTML.

Once again, however, the reality is not quite as neat as the press release would make you think.

For one thing, at the present time, it does not work in Netscape at all. (Apparently the trick of displaying database layouts on the web involves the use of some proprietary Microsoft CSS1 tags.) And my numerous experiments with it under both Windows 95 and the Mac OS lead me to conclude that it does not work 100% of the time even under Microsoft Internet Explorer 4.5 or higher.

For another thing, your user will not see your database's layouts exactly. He will at best see your layouts surrounded by a standardized FileMaker 5 web-publishing frame, which provides the various command buttons the user needs to do anything with your database. Since there are only a handful of these frames built into FileMaker, databases published using Instant Web Publishing are still all going to look alike. (The frames are supposed to have been "professionally designed," but even to my amateur designer's eye they look pretty bland.) Furthermore, we are talking look here, not functionality. Buttons on your layout that are tied to scripts will appear on the web pages but will not work. Only simple, not-script buttons such as a button that switches to another layout will work on the web page. This means that in the end, you will be creating special layouts for your web pages anyway.

It must also be noted that FileMaker Pro 5's web security is still weak. New in this version is the ability to specify that a file can be shared only with particular IP addresses. This is valuable. Of greater importance however is what is not new: the fact that Web Companion action that you trigger in your browser causes a wealth of information about your database to be displayed in the browser's location or status areas - the name of your database, field names, layout names, and so on. This is what appeared in Internet Explorer's location field when I searched for the Bach tee shirt in the products database that I created for this review:

http://10.10.10.10/FMRes/FMPro?-db=line%20items&
-op=bw&products%3a%3aproduct%20name=bach&-lop=and&
-format=zFormVwCSS.htm&-lay=ProductDetail&-max=1&
-skip=0&-token.0=25&-token.1=&-find

This line reveals the name of the database ("line items"), the name of a relation ("products::") which one might reasonably guess happens to use the name of yet another database, a field name ("product name"), and the name of a layout ("ProductDetail"). If you published your database using Lasso instead of the Web Companion, and if you used Lasso inlines instead of the old-fashioned Lasso tag syntax, you could hide this information from the user completely and permanently. It wouldn't even appear in the source code for your pages.

It is clear that FileMaker, Inc., sees the Web as FileMaker's future. I can't say that it is FileMaker's present, however. If you are getting married and you want to create your own online gift registry and host it on the iMac in your apartment, FileMaker Pro 5 Standard Edition would do the job splendidly - unless you have a lot of friends and relatives. For anything much more sophisticated than that, you are going to be looking elsewhere. If you want your web pages to look professional, you're going to have to get a professional page-design tool like Dreamweaver or GoLive and do the job right. If traffic on the site will exceed 10 IPs in 12 hours, you'll need to spend the grand for the Unlimited Edition. And if the site experiences even moderately heavy hits, you will want to employ middleware such as Lasso or Tango to take the burden off FileMaker, whose performance as a web application server does not appear to be improved in version 5. Neither the Standard Edition nor the Unlimited Edition is multithreaded, meaning that by itself, FileMaker 5 is no more capable of handling moderate to heavy traffic than FileMaker 4 was. (Apparently FileMaker 5 supports load-balancing, but that's been possible for a while with other CGIs.)

Lastly, I want to mention FileMaker Pro 5's support for XML. XML ("eXtensible Markup Language") is a cousin of HTML, "HTML done right," as one authority puts it. XML has a great number of uses, but it is attracting more and more attention as a way to share and format data on the Web. When the dust settles, this could turn out to be the most important dimension of FileMaker 5. Unfortunately, at the present time it is hard to say much about this, partly because the documentation for FileMaker Pro 5's XML support has not been released (it will come with the Developer Edition) and partly because at the present time, only Microsoft Internet Explorer 5 for Windows supports XML at all.

Limited, one-way ODBC capability appeared first in FileMaker 4.1, which could query data sources such as Access databases and Excel spreadsheets and import data back from them, but could not add records to a remote data source. FileMaker Pro 5's ODBC support is largely limited to ODBC level 1, but is now two-way. FileMaker Pro 5 now supports the SELECT, INSERT, UPDATE and DELETE SQL statements. It does not support the statements for creating tables and indexes, or dropping tables and indexes. This means that FileMaker Pro 5 can interact with other data sources in an enterprise, but is not going to be a major player.

On the other hand, Level 1 support is adequate for FileMaker to play a very useful role on the end user's own machine, or within a workgroup - FileMaker, Inc.'s, target market. Microsoft Excel has very good ODBC/SQL support, and FMI hopes that Windows users will increasingly think using Excel with FileMaker rather than Access.

It is a little trickier than FileMaker, Inc., would have you believe to configure your computer to take advantage of FileMaker's ODBC capability. The ODBC drivers you need are installed with FileMaker, but on a Mac, you still need to configure the ODBC Setup control panel, and this piece of software has to be the most opaque item in the Mac OS. The average user will wonder what the difference between a User DSN and a File DSN is, which he needs to install, what a "data source" is exactly, and so on. The control panel's help is, well, not very helpful. Furthermore, if you want to create queries in Excel (importing data into Excel from FileMaker), you will also need to have Microsoft Query installed, and if you want to get data out of Excel, you will need to install an ODBC driver for it as well. These are not part of the standard Microsoft Office 98 installation. When I first started to play with FileMaker 5's ODBC capability, I discovered that I did not have Query installed and I had to hunt around for the Office 98 master disk to find and install it.

But once you have everything configured properly, you can indeed pull data from FileMaker into Excel with relative ease. Microsoft Query (a helper application that is opened automatically by Excel) allows you to create an SQL query three ways. There is a wizard that will walk you through the process, although this only works well if your query is limited to a single data source. Alternatively, you can go directly to Microsoft Query and look at the data tables, create joins and define the columns (fields) you want, specify filtering criteria (price > $20), and preview the data before actually finalizing the query. The third option is to define the query directly in the SQL statement editor. Here, for example, is a query that finds data in the lineItems and products databases and displays a lists of products with prices and the options selected by the customer:

SELECT lineItems.productID, products.productName, lineItems.option, lineItems.cost
FROM lineItems lineItems, products products
WHERE lineItems.productID = products.productID

Once you have defined the query, you simply move the data into Excel, then massage it further in any way you like, chart it, move it into Word, and so on.

With its ODBC capability and its solid support for AppleScript (and now ActiveX on Windows), FileMaker Pro 5 is definitely a team player on the desktop. This is a much more truly useful feature of FileMaker 5 than the improvements to the Web Companion. All of my clients use Excel, and they find FileMaker Pro 5's ability to share data with Excel a development that enhances the value of the solution I built for them.

For years, clever users have pushed FileMaker to the limits and beyond - with an arsenal of parlor tricks - and gotten more from the application than anybody has a right to expect. Four, five, six years ago, when FileMaker's current reputation was being built, the DBMSes it was competing with were much more expensive, had longer development cycles, and often had much more power than the market demanded from a small database at the time. Starting at least with version 2.1, a small but significant number of developers found FileMaker a very viable alternative to the higher-powered alternatives, for certain kinds of solutions that were commonly needed in business. The fact that FileMaker ever got any respect as a developer's tool is due less to its built-in capabilities and more to the brilliance of these earlier developers.

But it is not a professional developer's tool. It has never really been. And now that FileMaker 5 has been released, I am pretty sure it will never be. This is not necessarily a knock against the product. While companies like ACI US (maker of 4D) market exclusively to professional developers, FMI is content to market almost exclusively to end users. Clearly FMI believes that it's product does what the majority of its customers want it to do. Of course, those of us who are in the minority - the developers - have the right to decide for ourselves.

The prices for all the FileMaker Pro 5 products are higher than the prices of the version 4 counterparts. And in the last couple years, competitors like Access and 4D had gotten easier to use, while remaining more powerful in most respects than FileMaker. FileMaker today is neither cheaper nor significantly easier to use than some of the much higher-powered alternatives. When I talk about "ease of use" here, I'm not talking about how quickly somebody with no training whatsoever can install the program and build an invoicing application. I mean, ease of use for developers, not the end user - ease of use for people who have taken a little time to learn how to use their own tools. It is a fault of much thinking in the FileMaker community to fail to distinguish between what is easy for the end user and what is easy for the professional developer.

In fact, for the developer - especially the independent developer who has the freedom to decide for himself what tools to choose - FileMaker is actually in many respects harder to use than the alternatives. Ironically, one new feature of FileMaker Pro 5 that I have not mentioned yet reveals clearly FileMaker's weakness in this respect. In FileMaker Pro 5, you can finally import scripts from one file to another. The feature works quite well. You select the file from which you want to import scripts, then select the scripts.

If the script does not require adjustment, it will import without any problem at all. For example, say you have a bunch of files in a solution, and you would like to implement context-sensitive help in every one of them. You could write a script in one file that looks like this:

If [status(currentmodifierkeys) = 8]
# the user has held down the option key
	Beep
 Show Message ["Shows context-sensitive help for this file"]
Else
	# put this file's name in a global field in Help.FP5
 Set Field ["help::global_originating_file",
		status(currentfilename)]
 # look up help articles based on the current filename
	Perform script [External: "Help::Get File Help"]
	# switch to Help.FP5 to view articles found
	Open ["Help.FP5"]
End If

You could then import this script into every other file (module) in your solution, and since it does not reference anything specific inside the file where it resides, it will need no adjustments. (All of the files will need to have a static relationship defined to the Help.FP5 file.) On the other hand, if you do import a script that does not fit perfectly into its new context - a field is missing, for example - FileMaker 5 will warn you so you can fix the problems immediately. Very nice.

But why is it necessary to have this feature at all? It is necessary because of what is perhaps FileMaker's most annoying weakness as a development tool: The fact that the data tables are inseparable from the programming and layout elements. In every other serious DBMS, data is stored in tables in raw form. Layouts and scripts are stored in a single application file (or a bundle of these files that behave in a more or less unified way). Then you don't need to copy the same code from table to table. The tables, after all, have no code attached to them at all.

Once upon a time - a long time ago, in a land far away - the decision to join the layouts and the data tables made sense, because it made things very simple for the end user. But it has not made sense to continue using this model since version 3, when FileMaker became relational four years ago. FileMaker's unique behavior in this regard has a number of consequences, and not a single one of them is desirable from the professional developer's point of view. I will list only a few.

Managing passwords and group access is a nightmare. A solution I recently completed uses a dozen data tables, that is, a dozen different FileMaker files (or "databases," in FileMaker's idiosyncratic terminology). There are twenty different passwords in this system, and the passwords are tied to four different groups of users, each of which has a different level of access. In order to enter these passwords and create the groups, I had to open every single file, type all the passwords in again and again (each time selecting the access options for the password), then define the groups again and again in every file, then assign the levels of access to the groups. This is not just a problem for the developer. Obviously, this kind of hassle discourages administrators from changing the passwords for complex systems regularly. (An "import passwords and groups" feature, similar to the new "import scripts" command, would minimize this hassle for the developer. But it wouldn't help the systems administrator who wants to change passwords.)

Achieving a consistent GUI throughout your solution can involve hours and hours of drudge work. FileMaker really punishes the developer who tries to give his solution a consistent look throughout. Say you have a solution that has ten files and a total of sixty or seventy layouts. You will find yourself pasting the same buttons into sixty or seventy layouts, rewriting the scripts in every file. Heaven help you if you change your mind later!

You cannot hide the data structure very well from the end-user. After all, the user inevitably sees the files, with their names in the title bar of every window. In many of my solutions, this ends up confusing the user, especially at first. If I do my job right, there is no reason for my users ever to have to think about how many tables (files) my solution uses.

Providing updates is tricky. When a 4D developer gives an update to a client, he simply instructs the client to throw away the old copy of the application and replace it with the new copy. The data files are separate from the application in the same way that your Word documents are separate from Word. But updating a complicated FileMaker Pro solution is a tricky - and risky - business. You can script the actual import to some extent, but the need to import the old data from the old files into the new files means that you have to give the user careful instructions on how to place the new folder next to the old folder, rename the old folder (so he doesn't get confused), and so on.

There are other problems with FileMaker, unrelated to the linking of layouts to data.

For example, FileMaker does not allow you to trigger a script or action when a user tabs out of a field after inputting data. This is something I miss every single day. (There is a third-party extension that does this, but this should absolutely be built into the program.)

In one critical area - data modeling - FileMaker's peculiar approach is a liability to end-user and developer. If the average end-user tries to define in Excel a query directed at two FileMaker tables at once, he is going to find himself in unfamiliar territory, scratching his head at references in Excel to inner and outer joins. Here is what Microsoft Query displays to the user who succeeds in defining a query based on an inner join:

Although this bears a resemblance to Figure 2, they are actually quite different. Figure 2 shows the view from the perspective of the lineItems file. But, Figure 7 has no such one-sided perspective. The table it displays belongs neither to lineItems nor products.

This is, in fact, a perfectly conventional representation of the data. In standard relational theory, a join is actually a tertium quid, a new table created when two other tables intersect on a key field.

But FileMaker users do not think this way. The average FileMaker user sees relationships as having a direction (in FileMaker, you can relate A to B, without relating B to A), and this leads them to think of relationality as a way for one file to borrow and display another's data. It is quite ironic that FileMaker Pro, which has such a great graphical user-interface, uses non-graphical dialogs for creating relationships, because this confusion could be eliminated if FileMaker did it the way Access, 4D, and even Excel do it, using an iconic tool like the one show in Figure 7.

Even worse, FileMaker allows you to create duplicate relationships, that is, to relate two files more than once using the same key fields. The graphical method of creating relationships used by 4D and Access makes this impossible. Four years ago, when I reviewed FileMaker 3, I thought it the most brilliant upgrade I had ever seen, because the product had metamorphosed into an essentially different thing - had gone from flat-file to relational - with almost no change whatever to the GUI. I now see that the metamorphosis was more superficial than I realized. A more profound transformation would have necessitated some profound changes to the interface.

Perhaps worst of all, because of the inadequate way in which relationships are modeled in FileMaker - because relationality in FileMaker is just a matter of one table borrowing data from another - FileMaker relationships are "shallow," that is, they don't go beyond the two files that are directly related.

Say you are creating a system that tracks students and classes. This is a classic many-to-many relationship. Every student can take many classes, and every class contains many students. In every DBMS, a many-to-many relationship between these two entities requires a join file. In FileMaker, this is not just a table representing the logical intersection of STUDENTS and CLASSES, but a full-scale database file, in which each record represents one student taking one class. Figure 9 shows how I would model the data for FileMaker Pro. Note that the join file must contain calculation fields that capture the data from the related file. If it were not for these calculation fields, the CLASSES file would not be able to display student information (other than IDs) and vice versa. Double-headed arrows indicate a double or two-way relationship, something that only makes sense in FileMaker terms: JOIN is related to CLASSES and CLASSES is related to JOIN. It's not a conventional ER diagram, but conventional ER diagrams don't quite make sense in FileMaker Pro.

In 4D, the model is much simpler. The join file, for example, contains only the two fields needed to define the join, the two ID fields. In 4D, it is not necessary to "capture" the data in the join file, because the join file is not a container at all, it is just a logical link. And best of all, relationships is 4D have a long reach. If table A is related to table B, B is related to C, and C is related to D, it's possible to connect data in A more or less directly to data in D, by following the thread of relationships. The duplication involved in long-range relationships in FileMaker runs contrary to the whole point of relational databases.

I could go on.

Note that I do not direct my complaints at the ScriptMaker or FileMaker's lack of variables. These are superficial weaknesses. The ScriptMaker is actually amazingly powerful. I would have been very grateful if FileMaker Pro 5 had made it possible to select multiple script lines and copy or cut them and paste them elsewhere. But the ScriptMaker is not the problem with FileMaker. Likewise, I do not mention FileMaker's still fairly immature support for ODBC, although this is a much more serious weakness in an enterprise environment.

I understand that rewriting the program is a major undertaking. Actually, with version 5, FileMaker Pro has gotten rid of the last bits of legacy Pascal code. The fact that, during the rewriting process, so little thought was given to redesign suggests pretty clearly that FileMaker thinks the product does exactly what it needs to do, to serve the audience that FMI cares about. It is now quite clear that professional developers are not part of that audience.

Conclusion

For end users, FileMaker Pro 5 takes a product that already served them exceptionally well and makes it even better. If you are in that target group, then by all means, upgrade and enjoy. On the other hand, if you are one of the many developers who have been dissatisfied with FileMaker's limitations, then this might be the right time to take a look at the alternatives.

For a little more information on moving data from FileMaker into Excel, take a look at Andy Ksasinki's article on the subject in the January 2000 issue of FileMaker Pro Advisor. If you are new to SQL, there are lots of books on the subject. Most of them make it seem complicated, which it is not. Ben Forta's SAMS Teach Yourself SQL in 10 Minutes (SAMS Publishing, 2000) is easy to follow and will have you creating sophisticated SQL queries in Excel in no time. The authority I quoted as saying XML is HTML "done right" is Simon St. Laurent, and the book is XML: A Primer, 2nd Edition: M & T Books, 1999. I recommend it highly to everyone interested in the future of databases on the web.

William Porter is the owner of Polytrope Solutions, a firm in Houston, Texas, specializing in custom database and Web-applications development. A member of the XXII Group, an international consortium of Web developers, Will has just finished a project in FileMaker Pro 5 that tracks newspaper circulation. He has recently become an ACI US Partner and has added 4D to his tool chest. You can reach him by sending e-mail to will@polytrope.com.