|
|
|
|||
|
Provides: Creation of standalone databases and
much more While not strikingly breaking any new ground from version 5.5, FileMaker Developer 6 maintains a strong presence for the creation of databases and royalty-free FileMaker (run-time) solutions. Besides supporting long filenames in OS X and Windows (not OS 9), this update almost exclusively brings the Developer version of FileMaker up to par with the newly released FileMaker 6 features. To read the new features of FileMaker 6, see Kirk Hiner's review and my review. For those of you unfamiliar with the "Developer" version of FileMaker, the following can better explain what this "flavor" of FileMaker Pro is for:
Originally, the FileMaker that one received with the Developer package was identical with the FileMaker that one received with the regular FileMaker package. FileMaker Developer 5.5 was a radical upgrade as it not only introduced a Mac OS X compatible version of FM Developer, but also, for the first time, created a release of FileMaker Pro that was different from the general FileMaker Pro release. For this new release of FM Developer 6, the upgrades from 5.5 are mostly to make it comparable in features with FileMaker Pro 6. Thus, much of what I wrote about FileMaker 6 applies to the Developer version of FileMaker as it follows (feature-wise) the new features of FileMaker6. As I pointed out in my FileMaker 6 review, the new bells and whistles for this release are somewhat limited (beyond the new XML capabilities). As such, much of what is new in FM Developer 6 over the 5.5 release is limited to what is new in FileMaker 6. Any recommendations I offered to upgrade to FM 6 would apply equally to FM Developer 6. I encourage you to read my review of version 5.5 (see my review) as that has some important information on the Script Debugger feature. One important upgrade from 5.5 is that now there are pop-up explanations of the various tools in FM, including the Script Debugger. I, for one, did not find the icons in the original presentation of this tool all that obvious and I welcome being told what they are supposed to be for.
In this review of version 6, I can elaborate on one feature I inadvertently passed in my review of version 5.5. It is not often, as a reviewer, that I get a good chance to make up for such an oversight, but fortunately I do have such a chance to present the Database Design Report (DDR) originally released in version 5.5. The DDR is a self-generated crib note for any database you create. In short, if you have ever created a database and then years later had to go back and update, repair, and/or enhance that database, you will wish you had a DDR report of the database. Created by selecting "Database Design Report..." from the Edit menu, any FileMaker files you have open (or open via a relationship) will automatically be added. (There is an inherent glitch in this but I'll get back to this later.) Once selected, you can verify which of the databases currently open you want in the report and whether you want the report saved as a FileMaker document on an XML document. This latter option is obviously an option of the new XML features of FileMaker 6.
From this Overview of the DDR, one can see how many Fields, Layouts, Scripts, Value Lists, Relationships, and Passwords were used in each of the database documents. By selecting (clicking on) any of the documents in the left column, one then can see all the information of that database, literally.
From any of the tabs, one can see any and all activities of the fields in that database. You can see which layouts those fields are in and any calculations, auto-entered data, validation, and scripts that use those fields. There is a place where you can enter comments about any of the fields if you feel that further explanation may be wise. Perhaps the best example of what the database report can do is in the Passwords tab. There is a list of all passwords used in the database and what access features each of the passwords can provide. Like I said, if you have ever created a database and years later you need to work on it again, don't you wish you had one of these reports when you finished? Needless to say, there are a few limitations. For example, nothing is backwards directed. Thus, for example, you cannot expand a passwords layout options from the DDR. If you observe that you failed to let a password into a particular layout, you need to go back to the database, make the changes and create a new DDR. The DDR is a report from the database; it is not a tool for interaction with the database. As mentioned, the DDR provides a report from all open parts of the database. If there is a relational link of Database B to Database A, (in FileMaker's "Window" menu you would see "Database A, (Database B)" indicating that FileMaker has Database B opened for relational purposes but no window of Database B is actually open). In this case, both would show up in the DDR. However, if there is a Database C which has a field being used as a Lookup in Database A or B, it would not automatically be included in the DDR. The way around this would be to simply open all the components of a relational (and Lookup) database as all databases that are open will automatically be included in the DDR. Amusingly, if you opened Database A, then closed it and then opened up Database G, a DDR created at this point would have Database G and Database B because the later remains virtually opened from before. There are two ways to get around this: one can either uncheck the file(s) when first starting the process (see below), or one can go as far as to quit FileMaker and restart.
One other curious aspect about creating DDRs is that the default name is ALWAYS "Database Design Report.fm5." While it would be nice for the DDR to take the name of the frontmost database, it doesn't. Also new to FileMaker 6 (and Developer 6) is the support for long file names. (This capability is not available in OS 9.) As with FileMaker 6, FileMaker 6 Developer is the last version of FileMaker that will be compatible with OS 9. For the next version (7), FileMaker will only be available in OS X and Windows. With that in mind, if you are a FileMaker developer, and you haven't upgraded lately, you might want to get this version if you plan on developing for OS 9. By the way, although a FileMaker database can be opened in OS 9, OS X, and Windows, if you want to create a run-time solution, you must create that solution while IN OS 9, OS X, or Windows respectively. As always, the FileMaker Developer Installation disk contains installers for OS 9, OS X, and Windows platforms. It wasn't that long ago that the only reason to get FileMaker Developer was for the ability to create run-time solutions. However, since version 5.5, the database creation aspect of the Developers edition has evolved into a "must-have" for FileMaker developers.  ___________ Gary Coyne has been a scientific glassblower for over 30 years. He's been using Macs since 1985 (his first was a fat Mac) and has been writing reviews of Mac software and hardware since 1995.
Tags: Reviews ď Business/Office Suites ď
|
Follow Us
|
|||
|
||||
Other Sites
