On Why Filemaker sucks

I just googled "filemaker sucks" and your site came up. Jackpot. I have to use this shit software 8 hours a day. It sucks.

I could write a 75 page white paper on why filemaker blows.

I googled Filemaker sucks too. What the hell were they thinking?

Cool. Thanks! And you're welcome, I guess ;) And re-reading this entry makes me appreciate even more, that I haven't had to work with Filemaker since! I knew blogs are good for something ;)

Good info! While you guys are busy bashing Filemaker, which I am considering buying, please provide an easy alternative. MS Access maybe? I don't consider learning Java or PHP+MySQL or those kinds of solutions to be easy. Basically, if you were forced to pick a Filemaker alternative for your pet ape to develop with and use, what would the alternative be?

thank you

Anything is probably better than filemaker. I mean BOTTOM of the list.

But go with access and SQL backend for a cheap solution that is flexible enough to do most things.

filemacker sucks with ubuntu laptops too. you can see at http://laptopadvisor.blogspot.com/

Oh nevermind. This ape just saw your Servoy pitch. Do you recommend any others?

They probably bought that rating. There should be some kind investigation because filemaker shouldn't get an award for being best at anything .... unless it is for being the best crap.

One thing I-m missing here...

Nobody seems to know what FileMaker is.

“I think one point you keep missing is that FileMaker Pro is an end-user database. You have chosen to use it as an application development environment, and while you are certainly not alone in having made that choice, those of us who develop "applications" using FMP must accept whatever limitations we run into as a result of its being an end-user database environment. That's how it was designed, that's how it's marketed. The product description for FMP 6 on FMI's web site says, in part (and it's the same for 7 and 8):

<>

Notice that it does NOT say: "FileMaker Pro is an application development environment that allows you to quickly create sophisticated solutions for resale to end users."

I would wager that among all the installed seats of FMP in the world, the redominance of them are in situations where end-users are creating their own little databases, either in a small-biz environment or in a corporate environment where FMP enables end-users to quickly roll their own, rather than have to ask (and wait for) IT to develop a database for the workgroup's specialized, "boutique" requirements.

The way things worked out, some people started exploring ways to "push the envelope" using FMP to develop "applications" as a result of entrepreneurship/ingenuity applied to FMP's relatively rich feature set, and IT departments use it to serve Mac or mixed-platform networks (or they simply want to develop centralized db's rapidly and need to modify them frequently and on-the-fly). It may even have come as a surprise to Claris that a community of "FMP developers" came to be, who demand such things as event triggers and custom menus and more sophisticated relational functionality. Those of us who call ourselves "FMP developers" must remember that the target market of the software vendor (FMI) is the end-user, with the chief attractions to the product being cross-platform capability, ease of use and ease of networking.

Well, when Billy End-user spends a couple of hours one day to slap together a Contracts database for his workgroup to share, do you think he needs custom dialogs? Would you think he even scripts the hiding of windows, never mind wants to learn sophisticated functions that control application window size, document window placement, etc.? Do you think he would understand the implication of event triggers? Does he care about putting in extra time to design what the custom menus would be in each file? I'd say chances are his FMP database is not even relational, probably does not even use scripts (or, if it does, only very simple ones), and allows full menus to all users.

Meanwhile - in response to loud demands, when it became apparent that a small group of people (a few thousand?) around the world decided to become "FMP developers" who create applications for others using the tool - FMI has indeed striven to incorporate into this product some of the features requested by dev's. (If you don't think many developer-oriented features have been added to the product, just try doing a several-hour-long development session using FMP 4 after you're thoroughly used to 5-6-7-8.) But FMI's mission, if it is to remain a profitable, enduring product, is clearly to continue to be marketable as the "easy to use" database. Developers are NOT FMI's core market, end-users are.

It would be interesting to see some real statistics on how many of the world-wide installed seats of FMP were bought because a developer had an FMP-based application to sell, versus seats that were bought because people heard about FMP on their own and wanted a quick and easy way to put together relatively simple solutions on their own. I'd expect that the latter category of customer is by far the larger category, and is the one that keeps FMI solvent.

We've all heard the news about great things underway at FMI, destined to appear in a future product release. While I certainly look forward to more powerful developer-type features being included in the product, at the same time my hope is that the engineers find a way to keep FMP easy to use for all those do-it-yourselfers (else risk losing a huge chunk of FMP's customer base). They have done so, and done it brilliantly, in the past, and I fully expect them to pull it off once again. And I wouldn't be surprised if some of the features you describe as being "basic," which might be true for an application development environment, are still not included (and may never be included) in a product intended largely to empower non-developers to create their own data-management solutions.(thanks to Ilyse Kazar).

And FileMaker did it with FM 7 and 8.

As a long-time user of FMPro, and one who likes it for specific uses and needs, I think Apple/FM blew it by not enabling FMPro to be a front-end to Oracle, MS SQLServer or MySQL. Yes, there is a very slow ODBC ability, but--since the advent of a division between data and UI in ver. > 7--if FMPro could be a customizable GUI to a more powerful database backend I think they could capture an untapped market.

I have to use this shitty software 8 hours a day too.. but I needed a job and they offered me enough.. so I'll put up with it.. Its tough for us that have worked with SQL Server or Oracle or any of the other big DB's

So just for the money…. That says enough about you….and your credibility.

Efficient : use the right tool. Your company does. Effective : do the right job. But with your skills no doubt you’re doing indeed a shitty job, don’t blame the tool.

I saw your posting and understand how you think someone's credibility is questionable by the language that they use, but FileMaker is all too often used for the wrong job! If you need a database for your home or home office use, it is pretty good, but there are too many companies that are using the product and are making developers, like myself, sick to our stomachs when we see what we have to support because someone decided one day that they are a developer too and their baby is too important to dump :(

That's also my point. Too many companies and developers are using FM the wrong way.

It is still an end-user program.

On the other hand, I make a living with repair FM databases who are build the wrong way. Even if FileMaker is an easy to use tool, it is a database tool. And like with every database, there are rules to follow. If you don't, sooner or later the whole application will hit a wall. But again, don't blame the tool for it.... Too many people consider: program is FileMaker, crapy program = crapy FileMaker. It's the way the developer was using the program (wrong coding) that is the culprit.

I was bit by Filemaker pretty hard. I bought the filemaker server software and allowed our old fm5.5 150 fields in 1 table database to be redeveloped in Filemaker 9 because I saw it supported ODBC. Which in my mind means you support ODBC so you can talk to other platforms and applications. I paid an extra 1000 dollars for the advanced package that gave odbc support. It turns out that the odbc drivers are only available for windows and OSX. WTF!!!! The whole idea of ODBC is cross platform/application functionality. These guys claimed PHP support for their DB and it was just marketing hype. It supports PHP on Windows and PHP on max osX but who really runs production websites that use PHP in Windows??? Or OSx? Everybody mainly uses linux! My whole concept was to make our filemaker databas info available on the web, my users could keep their filemaker db/program that they used for years, and we could keep FM in the company. Forget that, I can't get my production website plugged into my database.

Filemaker really sucks. Their marketing material is misleading. As an IT manager I wouldn't let this software into your company if I were you. You can't really make it talk to your other systems and all of the time and money you put into making the filemaker system is pretty much wasted if you grow to become a larger company.

>> It's the way the developer was using the >>program (wrong coding) that is the culprit.

Nope. Not wrong coding but rather they used the wrong tool. Is it always their fault? The choice of database is often forced on them by the powers that be..

Although this post may be attached to one person's post, it is not pointed at that person but to a thousand people with similar concepts...

Hmm, people seem to prefer bitching about Filemaker and the new guy who having bought a copy tried to create a database and now they have to repair it. Heck, those are bread and butter databases that will probably bring in $50,000 before your done. Why complain. Oh, just to try to convince the world that you are such a super duper developer, I see... Me, I'll tell the dude that I did the same thing when I began using Filemaker and here's what I do now.

Have you ever considered that your code and your methods might look just as bad to someone else? Or how your comments might cause you to lose respect in the listeners world?

The rant wasn't dated so I assume it is quite old as most of the complaints aren't accurate with the latest versions of Filemaker (8.5, 8.0, 7.5 and 7).

Filemaker 7 and up are capable of using one file for the gui and one for the data, much like 4D. This permits instant updates of the gui plus creating separate ones for sales, production, bookkeeping, etc. using the same data file.

It is now possible to copy layouts from one file to another and copy and paste scripts or selected lines of scripts which do not have to be contiguous.

Global variables are now included in 8 and 8.5, maybe earlier but I don't have 7.5 on my drive. $$name persists and works with all scripts in one file and $name works within a script and subscripts then disappears when the script ends.

Shipping with 7 and later is a tool to work with the server and can be kept out of the hands of those you don't want 'messing with the server." It is in a separate folder on the CD and can be copied to any networked computer.

Then rant is a few years out of date and that should be noted.

Hi Jack,

it's nice to hear, that Filemaker finally brings UI/Data separation to the table. On reading your comment I realized that the template for displaying a single blog entry doesn't contain the posting date of the entry, so I'd like to point out, that it was, in fact from 2003 and fairly accurate at the time ;-)

2003, huh. Heck I've been ranting on Filemaker for far longer than that. Fortunately a lot of the grumps I've made where heard and answered (such an ego) but even though I make a living using it, I still remember how much nicer 4D's dialogs and windows are, field events and layout events and events events...

Filemaker has thrown in a lot of new toys, some more sizzle than substance. I'm using 8.5 and creating dbs that some day someone is going to try to update and comment on how crummy my work is... :)

I must have missed something. I can not see seperate files for this. I see that they have consolidated this into one file, then utilizing tables, but the data is still in the file. If I am incorrect - please let me know where this data file is....

Dave

With FMP 7 and later you can separate GUI and data, but you're not forced to do so, nor is it the default method of working with FMP. Many of the so-called advanced developers choose to separate their data from their application logic and interface. Unfortunately it is sometimes necessary (or rather much much easier) to put some small part of the logic in the "data" file. And since the field is still the only programmable element in FMP, one may frequently have "fields" in tables within the UI file but these fields should not be considered "data" but rather data structures used by the application logic.

Not cross-platform yet, I think a Windows port is in the works:

http://www.glom.org/

I just got suckered into buying a $5000 upgrade to Filemaker Server Advanced 8.5, with the promise that it has "new" robust ODBC features. Reality...same small-time program with a few insignificant bells and whistles and embarassingly slow jerry-rigged ODBC. It takes at least 10 seconds to respond to a simple query. If you need a dirt-cheap solution for a tiny business, this one's a ringer. Otherwise walk, no run, away!

Suckered is right if you paid $5000 for an upgrade! What currency are you talking? Full version is $2500 USD, upgrade is $749 USD.

Lol, I googled FileMaker Sucks as well, must be a commonality :).

I had to call data from a client's filemaker database to be used dynamically on a website application. Needless to say, not only did filemaker force you to purchase a $700 upgrade to communicate with it in PHP, but the documentation was horrid! After 3 hours of installing, upgrading, and integrating into my local Mac workstation, I was apalled at the useless and ridiculous PHP-"Class" that they created to run scripts. One of the worst software companies I have yet come across.

Totally right about the University standards too. They would have forced them into another major after proofing that P.O.S.!

There really is no reason for me to post this this, but as someone that has been using Filemaker for four years now, I can say there isn't a simpler more robust database application on the market, for the small business or workgroup market. Which is what it is targeted at. Every project has a need, timeline and budget and therefor the tool that will best meet all of those objectives. For "normal" computer users the power that you can achieve in Filemaker is astounding. However if you are trying to write a major application for 200 + people you are using the wrong tool if you use Filemaker. Yes people have pushed the envelope to make it do that, but the skill level required to get Filemaker to accomplish it is high, and could have been better utilized in MySQL.

If you uses the tool for what it is intended to do it will outshine all others. If you try to get it to do things beyond it's reach you will have a difficult read to travel. Oh and the next version will be a front end to MySQL, which means it could become the best tool in the shed for robust rapid development of medium sized databases. (http://www.filemaker.com/mysql)

Filemaker is definately not the tool for you Web application.

I can't imagine it takes like half a minute to return 200 records from a simple layout by using lasso.

Yeah. lasso sucks too.

Be careful with Servoy ... we hired a programmer to re-create our Filemaker Solution using Servoy .... 2 years later and almost 200 thousand dollars later we ended up with nothing useful .... bad programmer yes, but the Servoy community seems shakey ... based in Amsterdam ... not very popular ... do a google search for Servoy and you will see that the only places you find this Group is on thier own webservers ..

caveat emptor !!!!

Perfect timing- We recently had a serious issue with the US based servoy community as well - we got involved with a Servoy recommended in fact, Servoy pushed him as a HEAD guru and Partner who turned out in my view to have serious drink issues- Servoy still support this person by linking to his site from theirs- Even though the fired him from the relationship he had with them. The support then offered by Servoy was basically to bad - we have plenty of others to collect lic fees from!!

I'm trying to find any independant reports on Servoy vs Filemaker ...

Are there any ? I can't find anything ....

Please post if there are.

Thanks

Yep, there's an independent developer who apparently had high cred in the FMP world, switched to Servoy, and documented the differences pretty deeply on her forums. See network.datatude.net

Any time I've seen customers post stuff like the 2 above posts from "Abby" and "DPR", and have known any of the facts about the situation, it has always been a bad situation caused by the Client as well. Anyhow, as for Servoy being shaky, I could not agree less. Servoy is a huge growth market. In use in many big companies around the world. Doubling in sales every year. Amazing work Servoy devs so is shown off at ServoyWorld conferences. So, who does one believe, developers who use the product, USC, MIT, USGS (all customers) or just a client whose project went down the tubes? Hmmmm. Lemme think 'bout that.

I chanced upon your rant and boy, I have to chip in. My company has been using FM8 for some time and yes, IT SUCKS. Couple mediocre-to-bad web support + CRAPPY DEVELOPER = NIGHTMARE. And still, I have to live with it! Anyone can suggest an alternative please add on to this thread!

Access

Vba code is versatile enough for most uses

and

SQL backend, quite reliable.

As a db developer I can say that using that combination yielded the best results for clients with least hassle for me :P

To get the Script Editor with keyboard shortcut: Crtl + Shift + S This is for Windows, not sure about on a Mac.

Just to say I've been evaluating this software and it is a really great alternative to FMP. Besides using our old friend javascript for creating methods instead of FMP's proprietary scripting language, and besides complete separation of the application & data layers, it also deploys with no code rewrite via browser, and also requires that you do not learn Java and not even necessarily SQL. To me this app is beyond 4GL.

Did I mention, Servoy Server is free, as opposed to $2,500 USD for FMS?

I will be migrating all my customers off of FMP onto Servoy, after reading the info at network.datatude.net and then checking it out for myself.

Another option is www.alphafive.com

also check out http://tomster.org/blog/archive/2003/12/07/on-why-filemaker-sucks/

meant to point to

http://www.forbes.com/businesswire/feeds/businesswire/2007/10/01/businesswire20071001006124r1.html

Want to organize your BeeGees record collection? Use FileMaker. Want to run your business? Use anything

I mean ANYTHING -- else.

I have been living, dreaming, reading, filemaker for the past two weeks, trying to move my Lotus Approach (great product, but long-in-the tooth) database into Filemaker Pro8. Five books lie with me in my bed, I follow each stupidly written (aren't all manuals?) guide precisely and still I can't get the dumb program to do what it is supposed to do. Nay, I am not a developer, I am only a physician, and perhaps my brain-set is on a different wavelength, however, Filemaker doesn't help; its help files, its "knowledge base" and all the accoutrements are useless and, furthermore, if you follow the reasoning, I believe you'll find that at bottom the company is only interested in the money, not the customer. I have to say the same for Alpha 5. I'd sure like to find a program that I could use without resorting to (ugh) Microsoft. If there are any suggestions, I'd sure listen-up.

Wow, sounds like a a lot of people on here aren't really aware of how to structure a solution properly and/or pick software for a project. We're a three member consultancy team and specialize in "fixing" filemaker solutions that have gone off the deep end of best practices, logic and sanity. I will agree that FileMaker is not for everything, especially high load situations and as a back end to high load web services. What I don't agree on is the 8th grade behavior that everyone on this thread is exhibiting. FileMaker is a tool no more no less, it doesn't suck anymore than trying to cut your whole lawn with the weedeater instead of a lawnmower sucks. The reason that many businesses have FileMaker databases is that they have been started by owners/technicians who didn't have the resources to hire/deal with developers or were in other situations (like education) where there were just not resources available to create a solution properly. What is a FileMaker solution that is structured properly? One that has a separation of Data and Interface. We have solutions in place running flawlessly on FileMaker, some that have over 500,000 records in each table and data file in excess of 8 Gb in size (our Pathology Laboratory Software. The interface files contain all the business logic, relationships and scripts and often do not exceed 15Mb in size. We never reimport data when we deploy, and never have the frustrations that most people seem to experience and whine about. We also use Lasso because it scales and is database agnostic. When you finally do outgrow filemaker and move on to an SQL based database there is no recode needed of web application. The Ruby API from sixfriedrice is another good example of being able to scale away from filemaker while keeping your code standard. You can't do this with the PHP API for FileMaker when you move to another db like PosteGre, MySQL (Sun), SyBase, or Oracle. Its unfortunate that more people aren't educated about what FileMaker is capable of, to that end we produced a video with Matt Petrowski at DevCON last year, and are working on a full series of educational resources about how to effectively split data and interface, eliminating portal problems, logic issues, deployment and more. The article, with the teaser video is at http://www.filemakermagazine.com/videos/data-interface-separation-discussion.html We welcome any comments and questions people may have.

I worked at filemaker and one of the developers said that he wouldn't use filemaker to store financial information.

No, FileMaker doesnot suck.. you just don't know how to use it. it has some negative aspects right but it provides a great and fast backend development.. that there is no other application i have ever used had it.

I have been using filemaker for 1 and half year now.. when i first started using it, i hated it.. Now after getting used to it.. It's a very good alternative for very high cost backend developemet.. you simply miss the whole point of using filemaker..

Also they are targeting small and middle business.. of course it sucks sometimes.. but in general i have to approciate how much money and time it saves for me and for the company i work with.

And no-one should be called doing shitty job because of working with FileMaker.. FM made 1.2 million dollar with the company i work with.. you simply have no idea what is it supposed to do.

Filemaker is the best thing that ever happened to our company. this software provide fast and cheap solution to our manufacturing, and it is the best thing that ever happened to our growth. for those who says its sucks, you just need to learn the basic before trying it for 1 week and decided it as rubbish. I love this program so much, I recommended it to lots of companies...and sure enough, they LOVE IT!

We (a manufacturing company) began using Filemaker about 3 years ago. It really has helped speed development of the systems that we have & provide simple UIs that people without english as a first language can use (all button driven). However one department (reverse logistics) found that they couldn't link Filemaker easily with an SQL database so they replaced it with Servoy. Their deployment of Servoy has been really impressive (tables with 4 million records and counting without issue) and it is likely to replace Filemaker with the rest of the company once the level of knowledge is sufficient internally. There is learning curve to Servoy which means that you either have to rely on consulants or spend a lot of time and effort in learning. Filemaker is easier for a non-programmer to learn so a department manager can administer the database. This IMO is FileMaker's big advantage. If a manager wants a report they simply use the knowledge they have gleaned to write it or ask for help. With Servoy that would be constrained to the IT dept, but using ODBC to the SQL the managers can still bring out the reports that they need. To us Servoy really feels like a step up from FileMaker. Now we just need to find its limits.

I would like to know if filemaker pro can do the followings like what Lotus Note can do for me now?

1) Can I create a request form, submit the form, and let a mgr approve the form via some buttons?

2) Can i assign different access roles so that different access roles view pages and buttons specific to their access?

3) Is it good with SAP in term of generating reports via excel?

Saying about - and doing something in - Excel is like saying: Only Windows should be used by everyone. It is as stupid as being in love with shits from Microsoft Corporation. I comment only shits of Windows fans - no FileMaker. I do not know FileMaker at all, but I know Windows (I have to work on this shit 8 hours a day).

I propose you learn how to use FileMaker Pro before you start ranting about it.

Actually whoever says FM is great, has no idea of anything. Without trying to be offensive, it is okay to not know everything - but if you have no idea of a topic, you should stay away of it.

FM is for quick app development? If you have an runnnig Apache with PHP installed and a SQL Database, I can create you a database, a form and the necessary PHP code before you even clicked half of the FM database together.

FM is extremely weak. The UI is ... I fight for words ... bad is just too "nice". Horrible at best. It's insulting for human eyes. I don't know of any UI that is worse. The user experience is also horrible at best. The whole concept behind the backend database is flawed, the form concept so broken by design.

Yes, it might take some time to learn a bit HTML coding, some PHP and SQL, but once you learned it (which is possible in about a month), you will see that you can do things that would take you hours of FM scripting and still yield for more than suboptimal results.

Very simple tasks that I need to do every day are completely impossible. FM Server is a joke. It's no server at all. While it imports data it blocks and becomes unusable to other tasks (like exporting a database). Our company uses it a lot, because non-developers see it as a great way to build an interface over a database. But almost 10 times a day I run into a situation where I have to say "What? There is no way to do something that simple? I need X extra tables, new relationships, 10 FM scripts and tons of AppleScript to automate all that for such a really, really simple task, that I could do on a LAMP system without a single line of code, just using a clevel SQL Select?"

If I'd earn $100 for every time FM is causing a complete work stop in our company, I could retire already. Right now our FM broke a database (no idea how it did that, but it did) and a bunch of data needs to re-imported. Since the same server is containing a string database that we need to export every day about 30 times to do our work... we now need to wait for the import before we can continue working. And during this import FM needs to delete about thousand data sets and what takes less than a second on every MySQL servers blocks FM now for over 30 minutes. Wow, isn't that a great piece of software?

I am an old time FM user dating back to 1988... but I'm not an FM basher. We set out 5 years ago to develop