What’s it For?

For the uninitiated, FileMaker is the most popular database program for Mac OS, and has the advantage of being cross-platform, making it a great choice for small- or medium-sized offices with mixed platforms. While the client version of the program is capable of hosting databases on the network for use by other computers, that capability is extremely limited (all the more so since the release of FileMaker 5.0). If you need to share a large number of databases among users, or if you need to share databases among more than a small handful of users (specifically, 10 different IP addresses over a rolling 24 hour period), you need FileMaker Server, as well as a separate computer dedicated to the task of hosting your databases.

FileMaker Server can host up to 125 databases to as many as 250 simultaneous users. (I’m hosting about 50 databases to about two dozen users.) These users can be running FileMaker clients from any platform FileMaker supports, but they must be at least version 5.0; this version of the server cannot host FileMaker databases older than version 5.0, nor are FileMaker 5 databases readable by older versions of FileMaker.

Installation and Making it Work

Installation is simple; there’s really nothing more to say about it. Drag the databases you want to host into FileMaker Server’s folder, start the “FileMaker Server Config” program, click the “Start Server” button, and it serves the databases.

Veteran FileMaker Server users will here pause. Click a button? I never had to click a button in previous versions….Yep. The disadvantage of making you click a button is obvious, and I’ll get to it in a bit. For now, a word about what’s going on. The program you launch is merely a configuration program; it doesn’t actually host any databases. The databases are hosted by a separate program, that you never see, and which has no user interface. It is possible to be hosting your databases even without the FileMaker Server Config program running…leaving no visible sign whatsoever on the computer that it is hosting all your databases.

From the “FMServer Config” menu, Preferences allows you to set how many databases the program should expect to serve, and to how many users (for optimum performance), how often to update its log, whether to open files that are marked for only a single user, and the password for remote administration, among other things. It’s laid out well, and is quite self-explanatory; you won’t need to resort to the manual here.

Schedules

The Schedules menu offers about the only other thing you can do with the FileMaker Server Config program: schedule tasks to be routinely performed, such as the backing up of hosted databases, or the running of an AppleScript. Unfortunately, it occasionally fails to run.

What the “back up databases” option should do, for example, is save copies of all hosted databases, without your having to close them down. That gives you backups (which I would then back up to tape using Retrospect’s public beta OS X client) without having to interrupt your users, or, for that matter, your busy self. Sounds like a great feature, but in practice, the scheduled task sometimes doesn’t run. Usually it does, but come on, we’re talking about backing up dozens of databases essential to an office’s operation. You can’t be shaky on backups.

Problems like that make it sound rather trivial to mention that in the “Schedules” menu, the “Edit Schedules” item is always greyed out; you have to select “New Schedule,” then cancel it, to be shown a list of existing schedules to edit. But hey, why sweat the small stuff when you’re not getting the big stuff right?

But wait! There’s more! Remember schedules being able to run AppleScripts? Well, they still can…but FileMaker Server 5.5 for OS X isn’t AppleScriptable. At all. (The OS 9 version is, as was version 3.0, way back in 1995.) This omission wouldn’t be nearly so glaring if the “back up databases” scheduled item worked reliably; since it didn’t, I figured, OK, I’ll just write an Applescript that runs at night, and shuts down the databases for backup, then opens them back up after Retrospect has done its thing. But that plan’s out the window without AppleScript.

Solving the Backup Problem

Yes, I did finally find a solution, thanks to a post by Jon Gardner, who was after a solution to that nasty “you have to press a button” problem. (What’s the problem? With previous versions of FileMaker—and with this version on OS9—it’s trivial to make the server start up when your computer boots: dump an alias in the Startup Items folder. That’s it. But with 5.5 for OS X, it’s not enough to make FileMaker Server Config start when you log in, because even with the program running, it doesn’t host anything until someone hits the “Start Server” button.) The important part of Jon’s post, for me, is this:

cd "/Applications/FileMaker Server 5.5/"
cd "FileMaker Server Config.app/Contents/Resources/"
./fmserverd start -c fmserver.conf

What is that? Remember those Unix underpinnings of OS X, and that un-Mac-like terminal window you swore you’d never use? (OK I actually like it…) Type those three lines in the terminal, and it will host your databases. Note that it matters not one whit (I always wanted to say that) whether you’re running FileMaker Server Config or not.

Next, I downloaded CronniX, a nice, simple program that gives a UI to cron, a Unix system service that lets you schedule activities. So now, on schedule, cron closes and opens my FMP databases. This works fairly reliably, but once or twice a month I find, several hours after the databases were supposed to be opened, that FileMaker Server is still trying to open them. When I hit the “Stop Server” button, I’m told the server lost contact with…the server! Starting the server after dismissing the error message is always successful, but I’m curious what strange sort of existential crisis my poor computer is having, trying but failing to get in touch with itself.

After I had all this working, I found where Jon got his idea: the “Using FileMaker Server in Red Hat Linux” section of the user manual lists commands intended to be typed at Linux’s command line. The only catch is you have to put a ./ first to use a command in OS X’s command line. Nowhere in FileMaker Server’s documentation is there an indication that these commands are available for the OS X platform, however. It’s a great feature, to be able to control FileMaker Server from the command line, but FileMaker really shot itself in the foot by keeping quiet about it in the documentation.

Documentation

While we’re on the topic…the printed manual that comes with FileMaker Server 5.5 (or which you have to pay an extra $20 for if you are buying in bulk) is a bit confusing. Presumably in the name of saving space, several chapters combine instructions for three different platforms (Linux users, the lucky dogs, don’t have to deal with this), noting with a parenthetical remark if what they are saying in a particular section or sentence is applicable only to one platform. This makes the manual a confusing read, since instructions that don’t apply to your platform are jumbled in with what you’re looking for. The odd mixture of screenshots, some from one platform and some from another, is also rather awkward.

That might all be forgivable, in the name of saving paper (hey, I like trees as much as the next guy), if the electronic documentation broke it down better. No luck; the PDF included on the CD-ROM is the same as the printed manual. No more than a day’s work by a single person could have broken it down into four smaller and more readable platform-specific documentation files.

New Features

There are a few really amazing new capabilities of FileMaker Server 5.5 which deserve mention. They’re new compared to version 3; I’ll indicate features which, according to the manual, are truly new to 5.5.

Top of the list, by far, is that a user can define fields of a hosted database, provided he/she is the only one with that database open. This is far more convenient than the old way, of closing the database on the server, making a copy to another computer, defining the field you want (or changing an existing field’s definition), closing the DB, copying it back to the server, and re-opening it. Many times, even, I found myself printing out field definitions, just to find out whether a field I was looking for was in the database, or to see how a calculation worked. (So much for those trees…) It’s nice to no longer have to do that.

New to 5.5 is the ability to allow guests to automatically download plug-ins (either new ones or updates) as needed and as available. Lots of third-party plug-ins are available for FileMaker, but do you really want to go visit each user’s machine, interrupting them in their work, to install a plug-in? Thanks to this feature, you no longer have to.

OS X compatibility is also new to version 5.5. With Apple pushing OS X harder than ever, making it the default system on new Macs, this is awfully important. Though I wouldn’t call this version any more stable than version 3.0, there are stability-related advantages to running on OS X.

Speed. In my users’ experience, version 5.5 is noticeably faster than 3.0/4.0 on Macs, particularly on things like the time it takes between clicking “hosts” from the “Open” dialog and seeing a list of hosted databases. However, my Windows users report version 5.5 is slower. This may well be more because of the client than the server, I don’t know. But speed is certainly a major issue if you’re considering upgrading, so I feel it’s worth a mention.

If you’re interested in new features of FileMaker client, FileMaker’s Web page has a pop-up menu from which you can select the version of FileMaker you’re using now, and be taken to a page showing what’s new compared to the version you selected.

Interface? We Don’t Need No Stinkin’ Interface!

Remember that first screenshot, way up at the top of this review? Well, let me tell you something…that’s not all there is to FileMaker Server 5.5’s user interface. Of course, Paul was pulling your leg. There’s no way that FileMaker, a company fully owned by Apple, which is known for its careful attention to user friendly interfaces, would call that a user interface.

What you don’t see in that screenshot is that the cog wheel actually moves! It’s animated! It turns at a nice steady pace as databases are being hosted, never changing its speed regardless of how much use the system is getting. Also, those three little lights next to the cog wheel….they blink! It’s like magic, one at a time, bouncing back and forth from the top to bottom and back again. I tell you, it’s incredible. I could watch it for hours.

And that, my friends, is the user interface, in all its glory. OS 9 users don’t get that. Take a look at what they have to suffer through:

There you go, just like FileMaker Server 3, only improved. OS 9 server administrators get a tabbed interface from which they can see which databases are hosted, open or close databases (To be fair, you can open databases from the OS X version, but you can’t close them, or see which ones are open; nor is any error message displayed if the file cannot be opened.), see which users, from what IP address, are on which databases, send a message to users, disconnect an individual or the whole lot of them. FileMaker’s manual calls that Local Administration, and it’s not available in OS X.

Remote Administration

Yes, there is a way to administer the server, and no, I’m not leading you along on another sarcasm-filled romp. Most the things you can do with Local Administration in OS 9 (notable exceptions include seeing users’ IP addresses, and getting a useful error message if a file cannot be opened. Under remote administration, you’re told the file could not be opened, but you are not told why.), you can do with Remote Administration (in 9 or X), in a similar-looking interface, which is actually a set of three FileMaker databases.

Unfortunately, FileMaker doesn’t give you full access passwords to the Remote Administration databases, so there’s no way to modify the layouts, check out the field definitions, or otherwise see what makes them tick. The manual specifically tells you not to try running Remote Administration in a copy of FileMaker (client) on the server machine. Any other computer, provided it has the necessary plug-ins (which it can automatically download from the server), can administer the machine with the administrator’s password.

But on a few occasions, I’ve tried to pull up the Remote Administration window, and it hasn’t worked. Here’s what should happen: You select “Open Remote,” and then click on the name of the server, rather than on one of the databases. Click “Open.” You should be prompted for the administrator’s password. Enter it, and up pop the Remote Administration databases. But sometimes that password prompt never comes up. When that happens, it’s no good to try from another computer; the same thing happens. Without local administration, you are left with no way to administer your server!

The only thing you can do at that point is hit that “Stop Server” button. Since there’s no Local Administration, there’s no way for you to specify how long your users have to log out of the databases, or to specify a message for them to see so they know what’s going on, or when the databases will be back online. Once the databases are all closed, and your phone stops ringing with calls from worried and confused users, you can start up the server again, go to another computer, and open Remote Administration.

Conclusion

You’re probably wondering, after reading this review, why I don’t just host my databases with FileMaker Server for OS 9. I am considering it. The time required to take everything down, install OS 9, install FileMaker Server, set it up, install Retrospect, see if schedules work in 9 and, if not, find a workaround, etc., is probably more downtime than my office could comfortably stand at a stretch, particularly at this time of year. Also, I have it running on a multi-processor computer; OS 9 can’t reap the benefits of the second processor, so my completely untested guess is that there might be some difference in performance. Finally, it’s rare, but I do occasionally have to open some other program on the server; if I do so under OS 9, and that other program crashes, it can bring the whole computer down along with it.

While the lack of AppleScript awareness is somewhat mitigated by the ability to control the server from the command line, the lack of ability to locally administer the server, unreliability of the Scheduling feature, and inability to easily make the server start when the system boots (though see the link above; there is a way), really make FileMaker Server 5.5 for OS X a disappointing program. If you’re planning to install this version of FileMaker Server, you should give careful consideration to using the OS 9 version instead.