Replacing FileMaker with Free Software? 445
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:
- 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?"
There's an old saying... (Score:5, Insightful)
well... (Score:2, Insightful)
Re:Filemaker Pro Migration software (Score:1, Insightful)
Re:There's an old saying... (Score:5, Insightful)
Re:web-based (Score:3, Insightful)
"""I can program data entry screens myself if I had to (either on the web or on the clients directly), but the printable layouts would kill me. Does anybody know of any package that will allow me to replicate FileMaker's easy interface for use with a RDBMS package such as PostgreSQL or MySQL? """
The bottom line is -- for "type-setting" browsers are GOD AWFUL -- they barely ( and badly ) support putting a header on each printed page via goofy CSS --- for the print media world, browsers are pathetically behind. He would end up laying out everything by hand, and have to tweak it for each printer -- *bah* -- god awful -- then if a new version of firefox/internet explorer comes out that thinks it should draw the table 1 pixel to the left -- broken again.
I would look for some conversation tool as some other posters have mentioned.
Web based software is great for a ton of projects, possibly even the majority of projects -- but for type-setting documents, it is just about the worst thing.
Re:There's an old saying... (Score:1, Insightful)
won't find a faster/easier to use option (Score:5, Insightful)
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.
Re:http://cocoamysql.sourceforge.net/ (Score:3, Insightful)
Anyways, as I commented before, this guys should stick with Filemaker 7. It *finally* has a lot of the same features as MySQL/PostgreSQL, so why leave it now? Especially when he has already a lot of work done in Filemaker 6 and prior. It would make no sense.
Re:Recode for Filemaker 7 (Score:4, Insightful)
Comment removed (Score:5, Insightful)
Why shift at all? (Score:4, Insightful)
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...
Re:DIY (Score:1, Insightful)
take a year off vs. pay for FM7 ?!?! (Score:5, Insightful)
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
Re:DIY (Score:4, Insightful)
Re:DIY (Score:3, Insightful)
The grandparent is not suggesting replacing a desktop solution with a Web-based solution,
Re:DIY (Score:5, Insightful)
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.
Re:DIY (Score:1, Insightful)
There, I fixed it for you.
Re:DIY (Score:5, Insightful)
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.
Re:GLOM! (Score:3, Insightful)
This is not stable or tested. It might completely destroy your data. I offer no guarantees and accept no responsibility.
Not quite ready for a prime time production solution.
Re:DIY (Score:4, Insightful)
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.
Re:Filemaker Pro Migration software (Score:3, Insightful)
Does this mean I can write access applications and distribute them to anybody I like for free? If so that's way too cool. I bet I can convince my company to stop paying for access on every desktop just to use a stupid application written by an employee.
Re:GLOM! (Score:5, Insightful)
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
Re:Recode for Filemaker 7 (Score:5, Insightful)
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.
Gaping hole in the Open Source Software (Score:5, Insightful)
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/ [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.
Re:DIY (Score:5, Insightful)
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.
Re:Gaping hole in the Open Source Software (Score:5, Insightful)
The biggest clean-up, hurry-up, clear-the-decks projects I've had to do are "office" databases written by some schmoe who showed it to an executive and now has to scale it up to the whole enterprise. The poor guy never planned for it to be multi-user, and he has to go hand-clean his data every couple of days because he didn't put constraints on the input, and there's no way he can support ten people much less ten thousand.
Get IT pros involved in the beginning -- sure we'll ask nasty questions like "do you really want to store the name all in one field" and we'll make the project take 5 times as long. Of course we'll raise questions about whether it's legal to keep this information and who the intended users are. But that's why they keep us around -- we're paid to think of the hard questions in advance, when you haven't committed anything to the project yet.
When you have to scale it up from 1 to 10,000 users and all we do is edit a couple of files and say "ok, done!" you'll thank us.
This is not about justifying my salary. This is about limiting the unplanned demands on IT and keeping you from propping your business unit up on a shakey foundation.
Re:Servoy (Score:3, Insightful)
Web Catalog Experience With FileMaker 5 (Score:1, Insightful)
Ah, the horrors of FileMaker 5. We're currently using it to enable a WWW content manager to update the product catalog for a B2B sales site. The manager makes her changes in FileMaker, exports to flat files and then I work my Perl and Oracle magic on it to populate the production database.
The only problem with this setup is that the developer that originally wrote the FileMaker database left the company and he provided absolutely zero documentation for the rest of us to follow. Trying to figure out just what each action does (I forget the name of the menu item) is next to impossible and the workflow for creating a new action is completely non-intuitive and cumbersome. I've also had weird problems where type declarations regarding exported data would cause certain information to just not make it into the resulting flat files. Just using the database that's been setup is easy as pie, it's when you start trying to make changes that things get confusing.
Our migration solution was to write a proper 3-tier web based application that housed the product data. The developer in charge of this project happened to use C# and .Net, but it should be a simple matter to create something with Apache, CGI, Perl and a RDBMS like mySQL or PostgreSQL.
I know you were looking for a different solution, but for us, a rewrite was the way to go.
Re:DIY (Score:4, Insightful)
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 ).
Re:DIY (Score:4, Insightful)
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!
Re:well... (Score:3, Insightful)
If he had understood that, we wouldn't have this entire article/question.
As for porting, FM does exports to text/cvs very easily.
Re:DIY (Score:5, Insightful)
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.
Re:DIY (Score:1, Insightful)
Did you notice in the story that the school is mac-based? Have you ever tried to access mac data files from a PC?
Re:DIY (Score:3, Insightful)
Like the poster I replied to, these types of comments typically don't offer anything more of use than pointing out what we all would agree is abvious... sure the asker could go off and program their own. If that were a viable option, then they probably wouldn't have asked slashdot. In fact, this asker even said that he didn't want to take that route.
Again, my primary gripe is that the poster didn't offer anything else to support this suggestion. It was wasted keystrokes without saying something like "Check out Hotscripts [hotscripts.com] or the PHP Resource Index [resourceindex.com] for a good place to start. In fact, check out FX.php [iviking.org] for something that will help you migrate from Filemaker to PHP." Answering "just do it in PHP/MySQL" and leaving it at that kills the thread usually without offering anything intelligent. I suggested (though I admit I was a bit crass) that posters like that provide more info and produce an actual constructive answer instead of an aloof and castrated suggestion that is offered far to often in ask slashdot replies. I've had my fill of them and finally felt I had to say something.
Fantastic FileMaker replacement (not free though) (Score:2, Insightful)
It's a Dutch product called Servoy [servoy.com]. There's a demo [servoy.com] available, a very helpful community [servoy.com] (the CEO, Jan Aleman (jaleman) posts a lot), and the manuals and other materials [servoy.com] are also available online for free. It comes with a Sybase iAnywhere licence out of the box (if it came in a box) but uses JDBC, and has PostgreSQL and MySQL support right off.
As you'll find out when you read the site, there is no file format; the solution is kept in a database. It also uses javascript as it's scripting language.
All in all, a very nifty product. And I'm not just saying that because we spent $6k on licences (previously we spent $3k on FMPro 5 licences, which were never used due to the product being inferior), I really do love working with it.
Re:Recode for Filemaker 7 (Score:3, Insightful)
Re:hard work, me boy! (Score:2, Insightful)
Re:Poster Clarifications (Score:1, Insightful)
1) If your solutions are zany they should be restructured. We are undergoing a similar update, and I'm actually looking forward to getting rid of alot of the cruft that has been put in place to put advanced functionality into FMP6.
2) FileMaker Advanced Server 7 (released yesterday) will allow you to communicate with the server directly. You can connect to it via ODBC, or JDBC if you need one of those standard interfaces, otherwise you connect via a web service or a direct query.
3) The SQL interface in Advanced server 7 is a significant upgrade over previous compatibility. The SQL engine is now fully ANSI SQL-92 compliant. You are correct that the feature is not currently on the Mac, but the extension to provide that functionality is to be available in the 2-3 month time frame, which is probably less time than it will take you to get moved to the new system anyway.
When FMP7 was released, I went through the same thought process as you, but having been actively looking at solutions lately, and attending the FMP developers conference this year, I am fully convinced that FMP is moving well in the right direction, and that currently the step up in database functionality is not worth the drastic drop in graphical development
Further, consider the support options. You may not always be around to troubleshoot some system that you make, or that someone else has started. Unless you find a very reliable source, you could just be screwing the system down the road when you can't get the support you need. With FileMaker, you do have an established source of support, and a pretty active development community, with consultants if need be, to take care of the migration for you.
So, I understand where you're coming from, as I am a developer. I hate FMP sometimes. But my personal feelings aside, it is a very viable solution for what it does, and I've yet to find another product that can match it in alot of areas, so don't hastily jump ship.
If anything moving from 6 to 7 will allow you to later make a move from 7 to something else that will be an all around smoother transition.
Good luck.
Well, besides the fact that you're wrong... (Score:2, Insightful)
"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.
No, it doesn't if you don't want to. You can just convert, but you won't take advantage of more than the software performance/structure benifits, until you actually change how your databases are built.
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)
At about this point I'm wondering what version of FMP you're using right now. It has to be pre 3.0, because that's when FileMaker went relational. Well over 10 years ago. I wouldn't consider it a toy at all. I would consider Access a toy compared to FMP7 (Not that Access sucks, quite the opposite, it's just that FMP7 has far far more capabilities than you seem to be giving it credit for)
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.
Like ODBC? XML? JDBC? XML/XSLT (For
I'm not sure how to respond to the rest of your article. You act as if FileMaker is the worst database program in the world, and has no scaleability (Not true, filesizes are at 4+Terrabytes, with 1GB of text per field, per record, with indexing services that scale perfectly fine whether you're at 40kb, or 3.5 terrabytes worth of data.). So my only conclusion is that you just flat out don't care to learn the benifits or functionality of using all the capabilities of FileMaker. That's fine, but don't poison the slashdotters minds with your lie based propaganda.
If you really want to start learning FMP7 and what it's capable of, check out some of the tech articles on the support section of the www.filemaker.com website. They should give you the general overviews of what you're missing, and the details are in a pretty robust help system within the application (Or server disk).
Re:Gaping hole in the Open Source Software (Score:2, Insightful)
The problem is Alice's boss thinking the single-user toy can be scaled up, where what really needs to happen is a proper professional implementation using Alice's tool as the prototype.
Forcing IT involvement at the low end when Alice is really just messing around, overloads IT and kills any innovation which involves IT - which isn't what we need. This is the very worst example of IT flexing its muscle and optimising IT at the expense of the rest of the company.
The best shops have a process for encouraging Alice to write these little apps, and engaging with her at the right time to productionalise them. And if Alice turns out to be a serial offender, she often ends up getting recruited by IT as a customer interface kind of person, and given some training in "real" IT systems.
Re:OIO? (Score:3, Insightful)
1) All of the data, queries and reports need to be stored in a single file, or a single folder. Even if that limits you to 2GB database sizes.
2) It should be easy to move that database from machine to machine using Windows Explorer. Backup copies should be as simple as closing the application, and dragging the file to the CD-writer.
3) Integrated queries and reports, stored in the database file along with the data. Bonus points if things work well on the web just by putting the database file up on a server and telling the web-engine portion where to find it.
Formats like MSAccess MDB files are easy for the user to manipulate. Very similar to working with an Excel file (tables are like tabs). No need to babysit their own personal copy of a SQL engine, or beg a DB admin to create a new field / table / database.
I'm semi-hopeful that now that IBM has released their java mini-database engine, we might see progress.