Slashdot Mirror
Replacing FileMaker with Free Software?
jhealy1024 asks: "I'm looking for a way to replace our FileMaker DB solution with an open-source RDBMS. Problem is, FileMaker's GUI and report design tools are pretty darn good, and I can't find a suitable replacement. Anybody out there have a solution that doesn't require me to take a year off to hand-code a replacement solution?"
"I'm the netadmin for a small private school. Since we're Mac-based, we've grown up storing all our data in FileMaker, including student information, grades, class assignments, gifts, inventory tracking, and just about anything else you can think of.
FileMaker is coming out with version 7, which is going to require us to tear all our databases to pieces and build them up again from scratch. While the new FileMaker is an improvement, it's still a toy as far as "real" databases go. (The latest update just introduced relational tables, for example). Also, data lock-in is becoming a problem; I'd like to have access to all our data from non-FileMaker interfaces (to populate our LDAP directory, for example). While we can work an export from FileMaker, it would be much better if the data were available in an open, standard database instead.
I figure, so long as we're rebuilding everything from scratch for version 7, why not use a "real" RDBMS (no flames about which, please). Problem is, FileMaker does two things very well:
Thus far, the only solution I've found is to use some kind of SQL access plug-in for FileMaker. This way, I get to keep the FileMaker interface but ditch its lousy relational model. Unfortunately, I'd still have to pay for FileMaker, and the SQL plug-in requires tons of extra coding to pass the data from FileMaker to SQL and back again.
I know other people have had to move from small, proprietary systems (FileMaker, Access, etc) before; what have you done to keep the simple user interface alive?"
FileMaker is coming out with version 7, which is going to require us to tear all our databases to pieces and build them up again from scratch. While the new FileMaker is an improvement, it's still a toy as far as "real" databases go. (The latest update just introduced relational tables, for example). Also, data lock-in is becoming a problem; I'd like to have access to all our data from non-FileMaker interfaces (to populate our LDAP directory, for example). While we can work an export from FileMaker, it would be much better if the data were available in an open, standard database instead.
I figure, so long as we're rebuilding everything from scratch for version 7, why not use a "real" RDBMS (no flames about which, please). Problem is, FileMaker does two things very well:
- Rapid development of front-end data entry screens (using a GUI for layout)
- Ability to create printable layouts for reporting (mail merges, report cards, etc)
Thus far, the only solution I've found is to use some kind of SQL access plug-in for FileMaker. This way, I get to keep the FileMaker interface but ditch its lousy relational model. Unfortunately, I'd still have to pay for FileMaker, and the SQL plug-in requires tons of extra coding to pass the data from FileMaker to SQL and back again.
I know other people have had to move from small, proprietary systems (FileMaker, Access, etc) before; what have you done to keep the simple user interface alive?"
If it ain't broke, don't fix it. If FileMaker has been good for your school, don't worry about replacing it with a "real" database. Many people don't need all the features of a "real" database, and all they'd get is more complexity and possibility of failure.
Javascript + Nintendo DSi = DSiCade
In spite of the fact that Filemaker Pro isn't a 'real database' - it's developed a well-earned reputation for being a quick & effective tool.
I'd stick with it unless you've got some genuine objectives/requirements that exceed its capabilities.
If you can't afford the licensing costs (which are modest), and have quite a lot of time on your hands - then there are a wealth of options. I personally like php/python + postgresql. But none of these options will match the development ease of filemaker pro. You'll be kissing that goodbye.
I'm not sure anything needs to be redone for FMP 7. It should open and convert your existing files. Of course they won't take advantage of any new features of 7, but the effort will be minimal. What's in the best interests of the school? Paying you to rebuild their existing tools from scratch or keeping the existing and easy stuff around? Are you looking for job security here?
"There are no cool guys in musicals." -- Coach McGuirk
Why is that everyone in the FOSS community always wants EVERYTHING to be a web-based application.
Is it so hard to imagine that some people really want application state, a really responsive UI, the ability to work with data without many round-trips to the server, etc?
Web-apps are nice, but geez, they aren't the frigging holy grail!
FileMaker is coming out with version 7, which is going to require us to tear all our databases to pieces and build them up again from scratch.
While any new features may be a bonus, if a program makes it so difficult to switch, and the current version does the job well (as you seem to suggest) I have to ask, why bother?
Look for the answer that's the least hassle...
Thus far, the only solution I've found [...] Unfortunately, I'd still have to pay for FileMaker,
You must either be paid exceptionally badly or deploying a huge number of FileMaker licenses if a year of your salary is a realistic alternative to upgrading to FM7.
This is not a complicated decision. Millions of businesses make similar decisions every day. Consider:
1. Do I need to upgrade at all ?
2. If so, WHY. (Answer this question, and you are done.)
- Do you need new features offered by FM7.
- Do you need features offered by some other database.
- Do I just need a major migration project in order to justify my salary and my department's budget.
Really, if your FM6 solution works today - why bother ? Every other choice, including the Open Source ones, come at a cost. If it does not work then you need to do a cost/benefit analysis of the alternatives and explain to your managers why FM6 was chosen in the first place.
-S
Drill baby drill - on Mars
They're looking for a new Web-based replacement for their existing Web-based application that was built in FileMaker--a web design product.
The grandparent is not suggesting replacing a desktop solution with a Web-based solution,
Well for one, if the tool is data driven, it just makes more sense to have the database on ONE SERVER rather than as part of an app that you have to store on a million different boxes and then update constantly. Second, one easy interface that everyone can reach and access make it easier to maintain.
Also, everyone is familiar with the web, the way it works and how to get things done. They don't have to figure out whatever GUI you develop for the tool.
It's portable as well as long as you have a connection.
For database driven apps, it's pretty much the best way to go.
This is my sig. There are many like it but this one is mine.
People usually ask these kinds of "ask slashdot" questions because they can't just sit down and roll their own. They are looking for genuine alternatives. Answers like this are akin to "You don't like your Ford? Just get a welding torch and some grease and make your own car..." A better answer would have been to point him to some coding resources directly related to what he's trying to do if you really wanted to provide an answer like "If you use such and such implemented in PHP, you'll be able to consider coding your own solution." Any moron can just say "make your own" without knowing what that really involves.
US Democracy:The best person for the job (among These pre-selected choices...)
Absolutely.
Rather than porting all that existing work, or seeking migration tools, just reinvent the fricking wheel. Waste your companies time fixing something that "aint broke". And use the weakest components available.
Next year rewrite it for Ruby+Firebird, the year after that, rewrite it for PostgreSQL+Perl. Waste as much time rewriting your app every time OSS nerds pick a new favorite scripting language or database engine.
Sheesh. And you wonder why you FOSS slashbots are unemployed.
I don't need no instructions to know how to rock!!!!
I guess you missed the part where printing was the main reason to keep filemaker or something like it. From the website:
Development is at an early stage, so it's not a complete database solution yet. The following future functionality should complete it:
* Virtual view fields (e.g. 'show the current price of this product in this field').
* Printing
* Reports
Ditto the parent.
I've created some horribly complicated db's in FileMaker. The kind that become huge systems as end users ask for lots of little parts to be added over the years.
FM7 converted all of those with only minor issues. Usually just GUI issues.
There are two types of people in the world: Those who crave closure
This is one of those big, gaping holes in open source software. I swear most open source programmers don't even understand the question. Let me try:
.net "way". Alice has to learn quite a lot to get there, though.
h tmlPythonCard, which is looking very nice: Python is a very newbie friendly language. If you use this, then ReportLab (http://www.reportlab.org/) might be a good choice for reporting tools.
Alice is an expert in some area of business. She can even wrap her head around simple databases. How can she write database apps without having to call Bob, the resident Unix hacker who doesn't want to waste his time coding simple data entry screens.
What tools can Alice use? Open Office is workable now, and although pretty clumsy, compares to the VB
There's http://pythoncard.sourceforge.net/samples/custdb.
There's Rekall, I've not used it at all, although it looks pretty good.
And then there is GNU Enterprise http://gnue.org/. It is eventually supposed to be an ERP system, but currently the project team is working on what appears to be a very sweet set of db app development tools. Rumor is that it's at a usable point, but I've never been able to crawl through the install process (even on Debian).
There are more, but I haven't found any really good ones.
Why is that everyone in the FOSS community always wants EVERYTHING to be a web-based application.
The unpopular reason that hasn't been posted yet is due to the circus involved in making a GUI application under UNIX. First you fight about KDE/GNOME, then GTK/Qt, packaging, installation, on and on and on.
Making it web based avoids all this, allows for much simpler development (PHP, MySQL, etc), and instantly creates cross-platform compatibility.
The latter are good reasons, but I think the former ranks as a dirty secret FOSS advocates would rather not talk about. I agree with your sentiment about web interfaces. I hate them less than I used to, but there are still times where a real application is much easier and faster to use than a web application.
Did you look at the pricing? Cheaper to go with FMPRO and thier server.
He said his school is an all-Macintosh environment. He has the luxury of going with a Macintosh-only solution, so a bit of the edge is taken off the "work from anywhere" argument. Not that he *should* build a platform-centric solution ( which FileMaker actually isn't ), but he could.
If he had the time/skill/resources, he'd probably write Cocoa apps. I know I would ( and do ).
For database driven apps, it's pretty much the best way to go.
Actually, it pretty much isn't. The web is a TERRIBLE interface for inputting mass amounts of data, is unreliable for smart clients and is much more difficult to support than a good client-server app. Unless you're faced with the possibility of a ton of heterogeneous clients making their own updates (such as a forum site or auction house), your best bet is to use a small footprint client for database management and save the website for more communal tasks. The web is really great at displaying data...that's what it was designed for.
As for storing an app on a million different boxes and updating constantly...this is 2004, Holmes. If you can't figure out how to get a client to update itself via the internet, consider going into an MIS field because you aren't cut out to be a programmer.
Finally, designing for portability and compatibility is quite often anathema to usability. If you want to make a ton of quick, easy changes in a reliable manner, stay the hell away from the web!
Hey freaks: now you're ju
I wholeheartedly agree. But I think the problem stems from people not understanding that database programming and development is its own field. Sure you can install and set-up MySQL, FileMaker, or some other database in a matter of minutes. You can also create simple or medium complex table and relational infrastructure in a small amount of time. But when it comes to creating something good or great, with a great user interface, that's flexible, extendible, and functions well under pressure, you need to make a commitment of time and energy, and hopefully some finances as well. And you need to seriously understand relational theory and UI.
FileMaker has been relational for a very long time. I've seen million dollar solutions built in it. I've built solutions that have cost nonprofits between $30-$100,000 (including nonprofit discounts). FileMaker 7 is better, especially about joins, security, and sheer volume of data to be stored. But if FMP wasn't meeting your needs, then the chances are: you selected the wrong database in the first place, or you don't have the programming skill (in FMP) to do what needs to be done.
I say this because, coding something in MySQL with PHP isn't going to make your life any easier. It's fine and a great opportunity, if your also dealing with making your data accessible from anywhere, or if you don't need super complicated reports. But your not going to code a solution in PHP/MySQL that your entire staff will be happy with in a month, any more than you could in FileMaker 7.
Actually, you could probably convert your current solutions to FMP7 within a month, so long as your goal was just to get and retain current functionality, without taking advantage of new features and functions that could streamline, speed-up, and further or better secure your data. FMP7 allows you to convert external tables to FMP7 external tables with external relationships. You'd have to adjust a few scripts, and maybe some calculations, but otherwise the solution will work. It just won't be optimized for FMP7.
Coming from a person who has a large number of database solutions and future projects in the making--FMP7 and MySQL dominate my development world, and more and more stuff is going to the web, but lately (last 6mo-1yr) I've been spending more and more time developing dual solutions: MySQL for all web and occasional desktop use, with FileMaker for reporting or high-end desktop use (anyone who needs to manipulate data in multitudes of ways, that doesn't have the time to learn the ends and outs of SQL.
Your end user is your bottom line, and even if you could program the most beautiful web-base solution and the world, someone will ultimately need to access information that you haven't created a report for. Which means they will need to go through you, or learn SQL and possible PHP on top of it.
That said, I currently have a client that I designed a 10 module solution, with probably 50 plus tables, that I plan on converting to FMP7, and if I can ever get started on it, my current estimate is about 3mo. work, and that includes rewriting security, and at least two modules to take advantage of new features, and making it a single file-multi-table database. Reprogramming the solution in MySQL/PHP would be at least twice as long, and without a number of the features of the current solutions.
I don't want to discourage anyone from PHP/MySQL because they're great tools, but so is FileMaker, so figuring out what your staff is going to be more comfortable with, and that provides them with the most benefits, and the least amount of training is generally a better way to decide.