What is FileMaker Pro?
FileMaker Pro is an alternative database development tool for Macintosh and PC. It was originally created for the Macintosh because Microsoft never made Microsoft Access available for Macintosh users. Since FileMaker Pro came onto the market, it has taken the Macintosh community by storm with its extraordinarily simple and intuitive approach to designing a database.
Due to FileMaker Pro's enormous popularity on the Macintosh, the application has become available to PC users as a viable alternative to Microsoft Access.
What are the advantages and disadvantages of the two applications?
The biggest advantage Microsoft Access enjoys over FileMaker Pro is its shear market share, especially in the corporate world. Too many corporate users have bought Microsoft Office and because it comes with Microsoft Access, most users don't see the point in changing over to FileMaker Pro.
Beyond that, Microsoft Access can allow multiple tables to be stored in one single file where they can be related and forms get created for selected or every table in the file. In FileMaker Pro, multiple tables require individual FileMaker Pro files to be created for each table before the tables can be related.
In early versions of FileMaker Pro (i.e. version 6.x and less) the file size for a database tended to be restricted. Microsoft Access databases tend to have no limit to the size of a file containing an Access database.
Microsoft Access has an enormous range of ready-made VBA commands for performing highly complex and flexible tasks such as reading and writing a Microsoft Excel spreadsheet and saving documents in XML and HTML. These commands help to give Access databases their power in doing many things.
However, in FileMaker Pro versions 5.x or earlier, users had to create third-party plug-ins to allow for extra features to be added to FileMaker Pro databases. In version 6.x, the ability to create XML and HTML documents became available as a standard inbuilt feature of the application.
Microsoft Access 2003 can now encrypt the text in fields of an Access database to ensure people cannot read the information using a Hex editor. FileMaker Pro's ability to encode information stored in fields is poor unless a third-party plug-in is developed and used with the database.
Microsoft Access also allows database developers to copy, paste and run whole chunks of VBA commands. Although the Visual Basic Editor will attempt to check the code, it does not stop the developer from saving and using the VBA code (i.e. programming text) in a database and running them when required.
In FileMaker Pro versions 2.x-4.x, there is no option to copy and paste hold chunks of code inside scripts within the ScriptMaker environment. Although this has been improved in versions 5.x and higher, if you wanted to include say an External() function code for activating third-party plug-ins which you don't have, you must have the plug-ins for the code to be accepted by FileMaker Pro and you must have the correct FileMaker Pro application version to accept the code.
There is also no option to tell FileMaker Pro to accept the code and store it in the database for later use (thus dealing with problems such as FileMaker, Inc. deciding to create a new plug-in calling architective as it did with the advent of FileMaker Pro 7 and higher). The problem with FileMaker Pro lies in its script testing environment and the company's desire to force people to upgrade the application to accept the latest and extra codes. You must type the scripts correctly to be accepted. While this helps non-programmers to ensure their code is entered correctly, it doesn't help the expert programmer to increase the flexibility and power of a FileMaker Pro database.
Furthermore, Microsoft Access allows VBA scripts to be attached to a wide range of Events such as tabbing out of a field, moving from one layout form to another, or setting a timer for the VBA scripts to run at specific times. FileMaker Pro requires third-party plug-ins to achieve the same things.
If we reverse the situation and look at the pros of FileMaker Pro, we discover that FileMaker Pro does not need to make any greater distinction in the type of objects you create. All there is to develop a database is a designing (or layout) mode and a viewing (or browse) mode. There is no need to complicate users with query objects, a proliferation of macro objects, reports and VBA code.
FileMaker Pro keeps the scripting environment (similar to macros and some VBA in Microsoft Access) simple and under the ScriptMaker menu command without interfering with the design of the database.
The scripting environment of FileMaker Pro utilises the best, most useful and easily understood English-speaking command codes for programming the database in almost any way you want. For example, you will not find FileMaker Pro overwhelming you with five different Loop statements to choose from. One Loop statement will do for practically every situation. Also you can perform a standard Find on your records by entering a criteria in any or all fields on a form and the Find criteria can be remembered in the scripts.
In fact, there is no need to open a separate window to enter find (or query) criteria on fields. All finding work is done on the same forms you browse normally using any field you see in the forms.
There is a finite and easily understood number of scripting commands in FileMaker Pro. By using a combination of such commands and making appropriate and easily understood changes to the essential parameters (or arguments) for each command, extremely effective solutions can be created to turn FileMaker Pro databases into commercial quality products considered virtually as powerful, certainly in FileMaker Pro 7, as Microsoft Access.
In Microsoft Access, you have to be overwhelmed with a couple of thousand commands in the VBA scripting environment. Many are obscure and requires extensive investigations and experimentation to determine what exactly they all do and how to use them in the right way. This can result in greater time being wasted in developing databases and can be very expensive to hire professional Access developers to do the job properly.
Also when running old FileMaker Pro databases on the latest application version, there is virtually no extra work required to make them run on the latest application version. Old FileMaker Pro databases developed on version 1.x will work on FileMaker Pro versions 3.x, 4.x, 5.x, 6.x and the latest 7.x. However, if you have built a Microsoft Access database in version 95 or 2.0 and want to run it on Access 2000 or 2004, the conversion is not complete and there is much work to be done to make the Access database compatible. You could purchase Access 97 to make the conversion less troublesome. But at the end of the day, the investment you make to an Access database is not worth it if the conversion is not perfectly done. FileMaker Pro, on the other hand, allows the conversion of older FileMaker Pro databases to be virtually perfect and work first time.
When it comes to making a self-running database where the user does not need the original application to run it (useful for selling the database solutions to customers), the tool for making this happen in FileMaker Pro (known as FileMaker Pro Developer's Edition) costs less than US$600 to buy and there are no further licensing issues and costs to worry about.
With Microsoft Access databases, it can potentially cost several thousands of dollars to make them self-running. And there is no guarantee the databases will be free of further licensing costs to Microsoft.
Also learning Microsoft Access completely including all the advanced VBA commands is extremely difficult and time-consuming. And not all Access professionals are willing to expose all the intimate secrets of Microsoft Access for free or in a single book that covers everything. You have to pay Microsoft and other training centres A$330 per day for the advanced level (double filters, macro writing etc) and around A$900 per day for VBA programming. Microsoft Access is truly an elitist tool.
FileMaker Pro defies this largely on the basis of keeping the database tool simple to use from a designer's point-of-view. If you want more features, you can create custom third-party plug-ins whose commands are easy for everyone to use and implement in their own solutions.
Finally, every subprocedure or function written in VBA needs its own error handling routine. There is no known way of directing all errors for every subprocedure or function into a single function where it can spit out an effective error message or perform other tasks after passing an error number to the function. This is considered inefficient for Access.
FileMaker Pro scripts allow errors to be captured and the number sent to a single error handling script where a message and the error number can be stored and/or displayed. Much more efficient.
If there is anything really negative to say about both database applications, it would have to be in the security aspects for developers.
Both FileMaker Pro and Microsoft Access have the lousiest security features for locking up the database from the prying eyes of users who may want to reverse engineer the database solutions. This is especially true for the low cost consumer versions of the applications. However, no matter how secure you can make Microsoft Access databases, you can pay a specialised password recovery software manufacturer around A$800 to provide the tool to uncover the developer's password. In other words, no Microsoft Access database is truly secure from a developer's point-of-view.
FileMaker Pro is slightly better in the sense that you can use a specialised third-party tool and a careful choice of a developer's password to lock a database solution to an almost impenetrable form. If you use the Developer's Edition, the scripts themselves can be rendered into a simplified and encoded form to help developer's stop the average users from peeking into the scripts, thereby rendering the database solution unusable for reverse engineering purposes unless you happen to work at the programming heart of FileMaker, Inc. where a tool can be used to recreate the scripts. But hopefully this tool would not be available to anyone outside of the company.
However, FileMaker Pro databases created in their standard form (i.e. not self-running applications created by the Developer's Edition) are definitely not secure products no matter what kind of tools or passwords you use. You only have to convert the databases from say FileMaker Pro 3-4 to FileMaker Pro 5-6 to render some security features added by the developer completely useless. Your only hope of protecting your investment is to use the Developer's Edition.
For Microsoft Access databases to have their VBA scripts properly locked in a similar way, they have to be saved as an MDE file.
Summary
To put it in a nutshell, FileMaker Pro was created from a designer's point-of-view rather than from a programmer's point-of-view. Microsoft Access was created from a Microsoft programmer's point-of-view, not from a designer's point-of-view. This is why Microsoft had to improve its Wizards and simplify the designing aspects of Microsoft Access in the latest 2003/4 versions.
However, FileMaker Pro was already designed to work in a simple way by focussing on the designer's point of view. As a result, FileMaker Pro has become the most popular database development tool outside of the corporate world.
And as FileMaker Pro further enhances the programming side of database development work to help people create truly powerful databases we may see more and more corporate clients use this tool for their own work.
Until Microsoft and FileMaker, Inc. decide to provide truly secure tools for everyone and not just developer's designed to lock databases permanently, neither application can achieve the level of security required for today's solutions.
Why do people prefer to use Microsoft Access?
Not everyone uses Microsoft Access. Apart from the Macintosh community, there is a large faithful base of ordinary PC computer users who have found FileMaker Pro to be an excellent tool for creating databases. But when it comes to the corporate world, there is a tendency to stick to Microsoft Access.
Why?
It is primarily because most businesses use PCs and because they have already paid for Microsoft Office, the availability of Microsoft Access as a standard component of the Microsoft Office suite has meant most businesses are happy to use what they are given. Why pay an extra A$275 for a standard edition of FileMaker Pro 7 if businesses already have Microsoft Access to do essentially the same thing?
But what if businesses had a choice between FileMaker Pro and Microsoft Access? Would business professionals continue sticking with Microsoft Access, or would they use FileMaker Pro if they knew it is easier to create databases and more cost-effective in the long-term?
The other reason is that Microsoft Access has been designed to read other documents in the Microsoft Office family in a very reliable way. This means an entire business with staff using Microsoft Office will have the confidence of being able to communicate effectively with other Microsoft products.
Yet, since 1999, FileMaker Pro 4.1 and higher has provided ODBC technology to allow people to access information in Microsoft Office products.
Perhaps the real reason is because FileMaker Pro has not been tried and tested in the corporate world to see how well it stacks up against the likes of Microsoft Access. And anyway, once people are committed to developing databases on Microsoft Access, the cost and time to convert the databases to FileMaker Pro often prohibits its use.
Is there a way to change this view?
UPDATE
September 2005
FileMaker Pro 8 has been released. Some of the features has been designed to imitate Microsoft Access. For example, instead of linking multiple files, you can link multiple tables in a single FileMaker Pro file.
