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:

1. Rapid development of front-end data entry screens (using a GUI for layout)
2. Ability to create printable layouts for reporting (mail merges, report cards, etc)

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?

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?"

Comments

PHP/MySQL

[viperone]

I'll agree with the PHP/MySQL option. Our University did everything using ColdFusion against an oracle db, php/mysql is actually better to script in (if you dont need the scalability of oracle) and we already had an oracle db for other things anyway.

Re:hard work, me boy!

[LiquidCoooled]

But thats the beauty, and the downside of Open Source/free solutions.

This guy is asking for our experiences, and pointers to locate a piece of code already written which will fulfill his requirements.

This is similar in a way to slashdot dupes, and patent prior art. If he reproduces code which already exists, then hes wasted 12 months doing something completely redundant.

Hopefully one of us will be able to suggest a path to an acceptable solution to his problem.

As it happens with this one, my thinking is "if it ain't broke...".

Exactly

[BoomerSooner]

Hammer meet Nail. But sir, I'm Screw.

Overkill isn't necessary, a quick, stable, and workable solution is.

Also I'd be inclined to know the posters skill level. Simply saying "I'm going to re-implement this system" is vastly different than saying "I know how to re-implement this in a better manner, any suggestions?". I get the feeling the poster may not have the necessary understanding of moving a simple project to a significantly more sophisticated design.

Or I could be completely wrong as my wife frequently points out.

Knoda

[mpieters]

I think Knoda sounds like an exact match. Feature list:

* define and delete databases;
* create, alter and delete tables and indices;
* add, change and delete data in tables;
* define, execute and store sql queries;
* define, execute and store queries with a "query by example" GUI;
* import and export CSV data;
* define and use forms;
* define and print reports; and
* write your own extensions using the integrated Python interpreter as scripting language

This is the Open Source equivalent of MS Access and Filemaker, except that it can use any database backend (native MySQL, PostgreSQL and SQLite support, plus ODBC). The report and form designers are full WYSIWYG GUIs, like the commercial counterparts.

Possible disadvantage? It requires KDE3, so it does require quite some extra bagage you don't normally find on a Mac OS X system, but it *should* work.

Re:web-based

[Anonymous Coward]

Though the browser printing issues you describe are real, I don't think they're the ones everyone else has in mind. The PDFLib part of these solutions means that for print, they are using the web application to generate PDF directly. Nothing to do with web browsers rendering html.

The real problem is that programming reports in PDFLib (or one of its many competitors, some Free) can be a little complex. There's no GUI layout helper, like Filemaker or Access has -- drawing a rectangle is a statement in PHP code, not a drag of your mouse.

Re:take a year off vs. pay for FM7 ?!?!

[Anonymous Coward]

I use Filemaker a lot - have several hundred databases that I have set up using FM and I use them several hours a day. Been using FM since it was a Nashoba product in 1986 and have databases that I set up 15 years ago that I still keep up to date.

I started out with Filemaker 1, upgraded to Filemaker 2, and finally settled on Filemaker 4.

Every time Apple comes out with a new version, I look at the features, try out the demo, and ask myself Question 1 "Do I need to upgrade at all?"

So far the answer has been no and I'm still using Filemaker 4.

What's wrong with what you've got?

[rufo]

Can you explain to us why exactly it is you need to upgrade? If your solution is in FM6, and works fine, why upgrade?

I work for a major database developer in the Rochester area. Our largest example is a manufacturing plant that's running entirely on Macs and Filemaker. The entire plant is on FM3/4, running on 6100s, 7100s, some 8500-era w/G3 upgrade cards, and a few G5/G4s for people who need them. At any given point in time there will be 30 people working in the database at once. The entire business has been running on FM for over 15 years.

You know what? Thing works fine. We just upgraded from an older G3/733 to a dual processor 1Ghz machine and run FileMaker Server 3 in Classic.

So upgrade if you must, but first make sure it's actually justified. Remember, not all proprietary software is bad - if the only reason you want to use open source is because it's open source, that's one of the worst reasons I could possibly think of. Pick the right tool for the right job. If you need to get data out, look into FM6 Unlimited and using XML/XSLT transforms, or web formats that a script could process - FileMaker's not a dead-end format by any means. Also check into FX.php - once you get stuff into PHP there's almost no limit to what you can do.

Re:also looking for easy, open src forms layout to

[Daytona955i]

Not if you go to a java type solution like oracle did with their Application Server. Very nice and very fast. Not free but there might be something out there like Oracle Forms?

Re:Recode for Filemaker 7

[lavaface]

I am currently working with Filemaker Dev 7 and while it may be easier to migrate, ultimately I think the better solution is to make the switch. Why? Because I Filemaker is limiting. Dialog boxes are limited to three inputs. Scripting anything of substance requires clicking on countless buttons. The interface options are nice but the process of writing the backend is arcane and obfuscated (to me at least.) Also, the documentation for FMP7 has been slow in coming, while there are multitudes of resources for Open Source solutions. Fmforums.com is nice but sometimes I find it sorely lacking.

One final point about Open Source--other people are working on solutions with you. PhpScheduleit is a nearly perfect match for our equipment reservation needs (once they implement multi-day reservations and quotas). Some of the webcalendars are also coming along quite nicely. I happen to work at a public university so I understand the submitter's needs. I would love to see a wider movement from public institutions to contribute to open source solutions (such as school management) I will be watching this thread closely for any ideas about presentation tools. Also, is there any equipment checkout projects underway out there? :)

Re:DIY

[dasmegabyte]

Web programming is NOT client-server programming, because you do not program the client. Instead, you issue a set client a series of cues on how it should interact with your server, which handles data processing as well as flow control.

The main difference between client-server programming and web programming is the role the client plays. A dumb client like a web browser responds in one way which is pre-ordained, and thus is unreliable in verifying data and presenting the user with information. The role of formatting and display is the responsibility of the server, and this cuts into the responsiveness of the UI. A smart client KNOWS what data it's going to receive, knows how to display it, and knows what data it's going to send back. This knowledge allows it to perform important pre-processing before the server is even contacted, which means less crosstalk, better response times and a more pleasant experience. It's also less stress on the server and if done right can mean greater supportability.

This is also discounting the fact that the web has no great way of performing many-to-many relationships, or loading information dynamically without replacing the current context. Can you imagine if every time you tried to write a bullet point in Word, the whole program closed and reopened?

As for "quick, easy changes occurring more easily:" dude, I used to be the backend programmer for a website ASP. I wrote a series of client tools to speed up what the customers considered an arduous, almost unbearable process: updating their website every morning with fresh content. Simply moving the interface from a web site (which was damned responsive, mind you) to a Java client dropped the time to load a manifest of articles from an average of 2 hours to an average of 45 minutes -- and it handled MS Word codes much better. Adopting a static Word aware client along with a Quark XPress scraping tool (try doing THAT on a fucking web page) brought it down to 15 minutes or proofreading. I don't remember smoking any crack when I did these tests, but it must have been the type of crack that gets you a nice fat raise.

Try Smalltalk

[chris_sawtell]

It's go a steep learning curve but the view from the top is just fantastic. There are many vendors of which Cincom is probably the best known. It has a superb data-entry form generator and several database interfaces. PostgreSQL is one. Also SmalltalkX offers a very good free (beer) implementation.