Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Databases Programming GUI Software

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:

  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?"
This discussion has been archived. No new comments can be posted.

Replacing FileMaker with Free Software?

Comments Filter:
  • by The I Shing ( 700142 ) * on Tuesday August 31, 2004 @01:36PM (#10120309) Journal
    Let me be the first to suggest FileMaker Pro Migrator [] by .com Solutions. I mucked about with the trial version of the program and it does look like it accomplishes quite a bit. And I guess that once you've got the data moved over, you could use a program like Dreamweaver [] to tweak the web-based interface.
    • I am facing a simliar problem and for the interim we used Access for the front end and a SQL server for the back. Since MS distributed the Access runtime for free, we can minimize deployment costs. I believe you can just add ODBC references for MySQL to Access to hold the data. This is a descent solution in a LAN environment. If you have any remote location that don't access via Terminal server or Citrix pulling any data across will be painful.
    • While not free, I would suggest something like Alpha Software []. The wizards to generate the forms and gui's are really good, and it uses a relational model.

      Their recent promotions are interesting:

      Alpha Five makes it easy to access your data from the Web, from your desktop, or even via email, no matter where you are, no matter what format your data is in.

      Build web applications easily and quickly using the Alpha Five .dbf engine, or with live data from MySQL, Oracle, MS SQL Server, DB2 or even MS Access.

  • by skrysakj ( 32108 ) * on Tuesday August 31, 2004 @01:37PM (#10120329) Homepage Journal
    If you ask me, recoding the database for Filemaker 7 would be much easier
    than going to another system/platform/application.

    The improvements in Filemaker 7 are vast, and much needed. It's a great platform, and unbeatable unless you move to a PostgreSQL&Web platform, which would require a lot more re-tooling.
    Look into a possible Filemaker 6 to Filemaker 7 conversion tool.

    In the future, if you truly need to use a different interface, such as the web, Filemaker is very capable of supporting that on its own, when placed on a server, without a SQL-access plug-in.
    • by Smokin Goat McGruff ( 19225 ) on Tuesday August 31, 2004 @01:47PM (#10120477)
      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?

    • by lavaface ( 685630 ) on Tuesday August 31, 2004 @04:36PM (#10122227) Homepage
      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. 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? :)

    • I agree with the parent. Face it, you are locked-in (isn't everybody?)!
  • by Anonymous Coward
  • by AKAImBatman ( 238306 ) <> on Tuesday August 31, 2004 @01:38PM (#10120352) Homepage Journal
    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.
    • by rjstanford ( 69735 ) on Tuesday August 31, 2004 @01:42PM (#10120403) Homepage Journal
      Absolutely. At some point you have to decide whether you're in the education business, or in the software design and support business. I would stick with the solution that everybody already knows - even going through an upgrade, you'll be so much further ahead faster than you would be by throwing it all out and starting over. You know FileMaker's quirks, after all - and believe me, everything has 'em, so knowing one set well is a good place to be.
      • by javaxman ( 705658 ) on Tuesday August 31, 2004 @02:48PM (#10121191) Journal
        More to the point, why even upgrade to 7 ?

        Yea, 7 has a lot of spiffy new features that make Filemaker less of a file-sharing system and more of a real server DB ( a *little* more, anyway ). But *must* you upgrade? They'll support your current version for a little while, right ?

        How about just looking into SQL-interconnect services, if you want to explore new front-end options ?

        If you want to put a 'real' database on the backend, first ask why. Is FileMaker too slow, or are you just looking to cut costs? If you're looking to cut costs, and your current system is working, just don't upgrade. If performance is a problem, then you have a big job- you'll have to learn a lot, and someone will have to do some design and coding. I'll recommend my favorite enterprise DB- PostgreSQL. Sure, there's a little bit of a learning curve, but it's really not bad, and you can do *anything*.

        So you want easy form design and reporting? Is that your main criteria? You might want to stick with FileMaker, then. On the other hand, you have a couple of good options, especially if you are a good enough programmer and have enough time to learn Objective-C.

        Your options, as I see them, are basically
        1) train yourself to learn Cocoa,
        2) annoy your users with web-based forms, or
        3) continue to annoy them ( and you ) with FileMaker.

        We've found that, especially for simple DB lookup stuff, throwing together a nice-looking data viewer or editor in Interface Builder is pretty darn easy, especially once you do it a couple of times ( can you say code reuse? ), and writing a real document-based app lets you do some stuff that'd be darn difficult and/or ugly in a web form ( or in FileMaker ).

        Of course, I don't know that all of your clients are on OS X, you don't mention. If you have a few OS 9 holdouts, you may want to go web-based or stay FileMaker.

        I'm sure some folks will jump all over me for suggesting doing real Cocoa programming as an actual option for you, but really- it's not that hard, folks, especially if you're doing fairly basic database stuff. This year I took a guy who had only ever written shell-level C programs, got him pointed in the right direction with Objective-C and Interface Builder, and he's written *several* great-looking, highly functional release-quality applications in the past 6 months. He wipped together one multi-user database app in, seriously, like 3 days. It's a real option and I'm a little sad that nobody has offered it up. On the other hand, it's not a simple 'no-programming' solution with auto-generated reports... one of the toughest things for us was learning how to do proper text layout for printing in Cocoa. Then again, once we worked out some details, we have results we couldn't get with FileMaker, and certainly wouldn't get with a web-based forms approach.

        Of course, I'm a bit biased towards a 'real programming' solution; before we went all OS X ( and for one project afterward where PC compatability was deemed worthwhile ), I was writing Java Swing database apps... which were totally useable, even with OS 9's antiquated JVM, and once the *design* was nailed down, implementation followed pretty quickly. If you're all Mac at your campus, your actual administration tasks should be light enough to let you do all that programming, right? ;-)

        Really, though, that's what we've found. I work at an all-Macintosh business, and our IT staff seems to have a lot of time to work on programming projects, rather than applying patches and fighting viruses. Writing database apps in Cocoa gets to be a pretty quick process, and PostgreSQL handles large, complex queries like a champ. It's a great combo.

        But honestly, it sounds to me like you shouldn't touch your system, unless it's too slow or has become hard to support. If you do replace it, do it slowly, in phases, and give yourself plenty of time to do the job right.

    • Exactly (Score:4, Interesting)

      by BoomerSooner ( 308737 ) on Tuesday August 31, 2004 @01:52PM (#10120549) Homepage Journal
      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.
  • web-based (Score:3, Informative)

    by stipe42 ( 305620 ) on Tuesday August 31, 2004 @01:39PM (#10120355)
    Web based really is the way to go. The tools are there for it (PHP for interface, MySQL or PostGres for the database, PDFLib or something free for reports). I don't know of any packages that already do that though. At work we are replacing our contact management system (in Filemaker presently) with one built in JSP with an Oracle backend. That same app is being sold to clients as well.
    • What the parent said. A few years ago, I talked my company into migrating from FileMaker (v.5, at the time) to a PHP/MySQL/PDFLib setup. (Save the PHP vs. Perl vs. Python and MySQL vs. PostgreSQL flames, please; this setup works for us, handling hundreds of thousands of dollars of business per month, and very nicely, too.) No, there's no one tool for such a setup that will replicate everything FileMaker does -- but the flexibility you gain is more than worth it in the end.
    • Re:web-based (Score:3, Insightful)

      by metacosm ( 45796 )
      Web based is not that way to go. Let me quote the question poster...

      """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
      • I think he sujested a pdf generating library in the mix, so I'm guessing that the printed media would be pdf and not html/css.
      • Re:web-based (Score:3, Interesting)

        by 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 co
      • Re:web-based (Score:3, Interesting)

        That's why he mentioned PDF. I've had lots of success using HTMLDOC to make reports. You make a regular HTML template (like what i use for all my stuff) some big table with bunches of report information and HTMLDOC coverts it to a PDF and takes care of all the messy page breaks, etc.
  • Is create an Access Data Project that links to the OLEDB/ODBC data source, thus pulling in the tables and keeping the Access interface. This works because we're already paying for Access anyway as part of our standard office build. I'm kind of surprised that File Maker doesn't offer something similar- Access has *so* many ways of doing this in comparison.
  • well... (Score:2, Insightful)

    by Anonymous Coward
    How about some details about why you need it replaced(unless price is the only problem ?) Because you just gave us the points that make FileMaker good...what's wrong with it ?
  • Servoy (Score:4, Informative)

    by Anonymous Coward on Tuesday August 31, 2004 @01:41PM (#10120388)
    Servoy is from the creators of the Filemaker SQL plugin. It uses ANY sql backend but provides a gui front end (100% java) just like filemaker. Real easy to setup and use.
    • Re:Servoy (Score:3, Insightful)

      Did you look at the pricing? Cheaper to go with FMPRO and thier server.
    • Re:Servoy (Score:3, Informative)

      by Deusy ( 455433 )
      Talking of Java, for designing reports you could always use DataVision [] which I thought was promising when I used it at v0.5 - the latest vesion is 0.8.2 although the website's CSS needs a bit of love. I don't remember what the GUI compared to, although at the time I was evaluating it as a replacement for Crystal Reports.
  • FileMaker Rocks (Score:2, Interesting)

    by Walrus99 ( 543380 )
    Been using FileMaker for our office for six years. Easy learning curve, easy (more or less) to use web interface. Tried MySQL and PHP but the learning curve was too steep for now. Not sure how 7 will be, but on 6 now and its working great. Now does anyone out there want to help me enter 500 city contacts? Whatever you use, you still have to do data entry.
  • PHP/MySQL (Score:3, Interesting)

    by viperone ( 648580 ) on Tuesday August 31, 2004 @01:43PM (#10120410)
    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.
  • Anybody out there have a solution that doesn't require me to take a year off to hand-code a replacement solution

    You know, if you work twice as hard it will only take you 6 months to create your own homegrown solution.
    • 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 i
  • by kpharmer ( 452893 ) * on Tuesday August 31, 2004 @01:45PM (#10120448)
    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.
  • Possible Alternative (Score:4, Informative)

    by nigmafyre ( 316209 ) on Tuesday August 31, 2004 @01:47PM (#10120469)

    I have had good luck using MicroOLAP Database Designer for MySQL []. Granted its not opensource, but its super easy to use. One quirk that I haven't sorted out with it is proper quotation of 'enum' and 'set' fields in its generated SQL. But, that being said, its still a slick interface.
  • GLOM! (Score:5, Informative)

    by tempest303 ( 259600 ) <<moc.oohay> <ta> <nostunksnej>> on Tuesday August 31, 2004 @01:48PM (#10120489) Homepage
    How about Glom []?

    It has a nice, clean GTK interface, and uses PostgreSQL for its backend.

    Good luck!
    • Re:GLOM! (Score:3, Insightful)

      by rjstanford ( 69735 )
      From the website:

      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:GLOM! (Score:5, Insightful)

      by Bronster ( 13157 ) <> on Tuesday August 31, 2004 @02:09PM (#10120735) Homepage
      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
  • by LodCrappo ( 705968 ) on Tuesday August 31, 2004 @01:51PM (#10120530) Homepage
    The meat of the article's question, which hasn't been addressed in the replies yet at least: is there an open source tool that makes generating forms (web based I would hope) as easy as you can do this in formmaker or access? For instance, is there a tool I can use to rapidly create data input screens with data validation or quickly throw together some screens that run queries with screen formatted results? The backend shouldn't matter too much, there are plenty of great open source tools to store and query data, but what about the user interface side? So far I haven't found a good solution that doesn't require manual html/php/perl/etc coding. (Not that I won't do that if I have too, but I'd rather have something more like ms access if it exists in open source, even if it's not as polished). any ideas?
  • Stop, drop and roll (Score:4, Informative)

    by joshmccormack ( 75838 ) on Tuesday August 31, 2004 @01:51PM (#10120532) Homepage Journal
    I've worked with Filemaker a fair amount, and moved apps over to web based systems with other databases.

    The most recent versions of Filemaker, when treated just right, may be a blessing, but in my experience Filemaker just doesn't scale well. After you've started really putting a lot of data in there it creeps. It is it's own thing, too, so you can't use standard database modeling, reporting, etc. And hosting is an issue.

    The impending new version might just be your occasion to stop, drop Filemaker, and roll your own.

    Finding a tool to move the data and structure over is tempting, but consider whether the database structure you have is a good one, and if all your data is normalized. This would be a good opportunity to work on that, if you'd be moving to another system anyway.

    And try thinking using the Unix philosophy. Use differnt tools. Use a database to store the data, use an off the shelf reporting tool (ie crystal reports) if you want, use Access or Filemaker to allow clients to make custom views, use modeling tools, etc.

    Contact me if you want sympathy or some help.
  • Why shift at all? (Score:4, Insightful)

    by doodlelogic ( 773522 ) on Tuesday August 31, 2004 @01:52PM (#10120550)
    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...
  • Rekall Revealed GPL (Score:5, Informative)

    by wackysootroom ( 243310 ) on Tuesday August 31, 2004 @01:53PM (#10120552) Homepage
    Rekall Revealed [] (GPL verson of thekompany's rekall product) can do all that, connect to PgSQL and MySQL, while using python as the language backend. Very nice, *and* Free Software.
  • The real problem (Score:3, Informative)

    by howardjp ( 5458 ) on Tuesday August 31, 2004 @01:54PM (#10120577) Homepage
    The real problem this user has is one I have had. There is no suitable replacement for Access, FileMaker, or dBase. An open-source portable replacement would be a killer app for the open source community, but it just isn't there.
  • by sjf ( 3790 ) on Tuesday August 31, 2004 @01:56PM (#10120590)
    Anybody out there have a solution that doesn't require me to take a year off to hand-code a replacement solution?

    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.


    • by Anonymous Coward on Tuesday August 31, 2004 @02:13PM (#10120771)
      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.

  • by greed ( 112493 ) on Tuesday August 31, 2004 @01:57PM (#10120597)

    If you read the linked article [] on FileMaker's website, it says:

    Now store multiple database tables in one file instead of having to break them up into multiple files.

    I've been using FileMaker at home since it was made by Claris, back at version 3.0. It's always been relational. You build relations between files--one file is one table. Now you can have multiple tables in one file. And you can still build a relation to a table in another file, so you've got the best of both.

    In fact, using the free demo of 3.0, I built a database with about 25 relations in it, entirely without the manual. Consequently, I was out to the store the next day and bought the real thing. I've upgraded to 5.0 and 7.0 since.

    I'm not sure how much "re-writing" is required to upgrade, I just load all my databases from the old version into the new one and let it create new files in the current format. I've never had to change the database definitions.

    (It would be nice to turn a couple of my DBs into a "single file with multiple tables", but hey, it works fine in multiple file mode, so like others say, why break it?)

    There are times when it Would Be Nice to throw some really grotty SQL into the system. But they're fairly rare.

  • Knoda (Score:5, Interesting)

    by mpieters ( 149981 ) on Tuesday August 31, 2004 @01:57PM (#10120608) Homepage
    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:Knoda (Score:4, Informative)

      by Bronster ( 13157 ) <> on Tuesday August 31, 2004 @02:19PM (#10120841) Homepage
      Have you tried using it? I tried against a postgres backend (to check out some databases I already had) and the interface isn't quite what I'd expect for a Filemaker or Access replacement.

      You can't even see views in the database.

      No way (that I can see) to store connection information for more than one backend server. Ok, that's not the end of the world. At least you can make it cache your connection details.

      The interface is a little strange with database as a dropdown list in the toolbar, and also a tree-menu at the side but with only one parent database entry at once.

      Did I say "no views" yet?

      Still, I guess if you're starting from scratch it isn't so bad, and it does fit in reasonably in KDE. Needs some work on the sidebar treeview not overlapping the database windows though. Definitely looks more complete than the gnome offering.
  • Gnu Enterprise (Score:3, Interesting)

    by MooCows ( 718367 ) on Tuesday August 31, 2004 @01:59PM (#10120635)
    Gnu Enterprise [] might be just what you need.

    It's not very 'complete', but very extensible.

    Look at the pretty screenshots [].
  • Rekall, OOo (Score:3, Informative)

    by iantri ( 687643 ) <iantri@ g m x .net> on Tuesday August 31, 2004 @02:02PM (#10120660) Homepage
    AFAIK, there are two semi-feasable choices:

    Rekall (available in commercial or GPL licenses) is a MS-Access type thing -- it can hold a database in its own format and create forms and reports (like FileMaker) or you can connect it to an SQL server. Last time I tried it was in the v2.2x days, and it would crash just trying to open the demo database. That was on Linux, the Windows demo (NOT GPL) simply crashed before opening. Not good for a software that is supposed to be in its second major version. Maybe it has improved since, though. Not sure if there is a Mac version.

    The other option is Openoffice. It has a database form and report mode, but you will need MySQL or PostgreSQL at the backend. Also, there is almost no documentation for it.

  • by apropos ( 12176 ) on Tuesday August 31, 2004 @02:12PM (#10120761) Homepage
    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:

    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 .net "way". Alice has to learn quite a lot to get there, though.

    There's tml []PythonCard, which is looking very nice: Python is a very newbie friendly language. If you use this, then ReportLab ( []) might be a good choice for reporting tools.

    There's Rekall, I've not used it at all, although it looks pretty good.

    And then there is GNU Enterprise []. 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.
    • by Anonymous Coward on Tuesday August 31, 2004 @02:34PM (#10121039)
      For God's sake chain Alice down! Force her to go to Bob! Here's the problem, for you lurking management types:

      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.
      • Not realistic (Score:3, Informative)

        by nobodyman ( 90587 )
        Your solution the problem you describe is a bit like cutting off your legs because you want to avoid ingrown toenails. Would you really bar anyone from making any sort of small scale solution until they pair up with a programmer? First off, few organizations have an IT department large enough where you could meet the demand (this is one of the reasons why people make apps in MS Access... they can't get a resource in IT). Furthermore, when you're designing at the MS Access level, you can change your a
  • School Tool (Score:5, Informative)

    by steveha ( 103154 ) on Tuesday August 31, 2004 @02:12PM (#10120765) Homepage
    School Tool is a system specifically designed for running a school. It's written in Python, and it's free, open-source software. []

  • My suggestion (Score:4, Informative)

    by Pan T. Hose ( 707794 ) on Tuesday August 31, 2004 @02:20PM (#10120844) Homepage Journal
    Unless you have some legacy MySQL applications, I would suggest using PostgreSQL--it's really free with no strings attached, it's ACID-compliant and it's a real RDBMS. In the past it was slow but not any more. When in doubt read: [1] [] [2] [] [3] []. To be fair, there is one place where MySQL beats PostgreSQL, and that is the documentation. For example, you will often find unfinished parts of PostgreSQL documentation turned into "Exercises":

    "This query is called a left outer join because the table mentioned on the left of the join operator will have each of its rows in the output at least once, whe reas the table on the right will only have those rows output that match some row of the left table. When outputting a left-table row for which there is no right -table match, empty (null) values are substituted for the right-table columns.
    Exercise: There are also right outer joins and full outer joins. Try to find out what those do."

    when there really should be:

    "TODO: There are also right outer joins and full outer joins. FIXME: We MUST write more."

    Not to mention the "RTFS" answers in "TFM" for questions very frequently asked by beginners:

    "4.3) How do I get a list of tables or other things I can see in psql?"
    "You can read the source code for psql in file pgsql/src/bin/psql/describe.c."

    Other than that I would say that PostgreSQL is definitely the way to go today. Once you get used to reading the source code as documentation (it is actually very clean and properly commented, so that's not such a big deal), you will really love it. And you will have the most important thing: ACID features. I hope it helps, I wish you the best luck.

    See also:

    1. []
    2. []
    3. []
    4. []
    5. rver) []
    6. []
    7. ystem []
    8. []
    9. []
    10. []
    11. []
    12. []
    13. []
    14. []
    15. []
    16. igrator/index.html []
    17. []

    (Please forgive me if I repeat anything which has already been said. I started to write it as a first post but it took some time and I am sure that other

  • by perlchild ( 582235 ) on Tuesday August 31, 2004 @02:22PM (#10120876)
    perhaps you could look at the new alpha5 version 6.0 that's coming out, they seem to be touting it as a sort of filemaker-meets-dbase-meets mysql-backend type of hybrid relational model with an easier to use interface. My impression of their press release is that they're offering a type of "dbase for local, mysql for web" filemaker pro replacement.
  • by JohnsonWax ( 195390 ) on Tuesday August 31, 2004 @02:24PM (#10120897)
    We looked at precisely this and decided to use FM7 as an intermediary decision point.

    FM7 allows full data/interface separation so our systems are being reworked in this manner. This allows us to later decide if FM7 should serve as an ODBC source to PHP, or as a front-end to MySQL, or what.

    Servoy is on our radar, but once you leave FM, you might find that your clients really hate all of the other solutions. FM is really exceptional at quickly putting a solid client/server solution on users desks that is usable.
  • by rufo ( 126104 ) < minus berry> on Tuesday August 31, 2004 @02:51PM (#10121231)
    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.
  • by dheltzel ( 558802 ) on Tuesday August 31, 2004 @03:05PM (#10121384)
    Before you set out to blindly replicate the current functionality with a new custom solution, you really should ask yourself "who else has had this problem and how have they solved it?" I'm not talking about the "porting problem" here, I'm talking about the overall "problem" that your current filemaker s/w handles.

    If you can identify similar organizations with similar problems, you might find an existing program (hopefully OSS) that you can just start using. If you need to customize it a bit, that will be a whole lot easier and cheaper than trying to roll your own solution, and the changes you make might be used and appreciated by others who use the program.

    There is a lot of existing work that is being wasted because we start off assuming our solution is too highly customized to be changed. You might pick up enough shiny new features you never had before to make your users willing to put up with a few tradeoffs.

    Maybe you will look and not find anything useful, but do look really hard before you just port your existing code.

  • Similar exp (Score:3, Informative)

    by FictionPimp ( 712802 ) on Tuesday August 31, 2004 @03:24PM (#10121572) Homepage
    I had a similar task at my last job. I was working for a small medical billing software company. They were using an old DOS based app one of their programs wrote over 10 years ago to store their client data. The only problem was it was not really designed for multiple users and with the rate that the company was growing it was getting hard for support (who was logging calls on notepad and entering them in by hand at the end of the shift) to share. After much searching, I ended up using the 2 cheapest tools I had to work with (and the only one's my company had on hand as my budget was small). I used our web server with php and mysql. I used phpmyadmin for a stop gap mesure to printing out reports, and started writing an entire Client managment system in PHP. I had to build the database by hand, and found out the original system was an old btree database. I few custom scripts and I had the data converted over and a database designed to grow with the company (for example, more then 1 contact person and phone number). The system grew from there and eventually I moved all of their billing and created reports with crystal reports.

    I've sense moved on to bigger challenges outside of that company. But from my contacts there they have grow a lot in size and still use it today. I hope my design will last at least as long as their last solution, and hopefully will be a lot more flexable.

    The point of my babbling is that their is really no better solution then a custom one if you have the time. If I was still employed there with what I know today, that application could of grew to be much much more for that company. Plus, based on my salary at the time, they saved way more money then buying a good pre-built solution.

    P.S. I'm sorry who ever took my job if you had to read my comments.

  • Omnis Studio (Score:4, Informative)

    by ThadMan ( 171233 ) on Tuesday August 31, 2004 @03:38PM (#10121710) Homepage
    It's not free, but Omnis Studio [] is an extremely capable tool for building front ends and reports for client server DBMSs. It is capable of connecting to most databases out there; through either native connections or JDBC and ODBC. An Omnis application can be run on the Mac, Linux, Windows, and Solaris with little or no code changes. It even has a web client plugin that allows you to embed a GUI application into a browser window.
  • Progress RDBMS+4GL (Score:3, Informative)

    by isj ( 453011 ) on Tuesday August 31, 2004 @03:55PM (#10121866) Homepage
    You may want to look into Progress. I has its own relational database, but can use Oracle, DB/2, MS-SQL, ... Its 4GL is powerful, and you can use its user interface builder to make data entry screens very quickly.
    Its printing capabilities are moderate, not good, not bad. I don't know the price though.
    Unfortunately it is mostly geared toward business and is a bit pricey. But who knows - maybe they are hungry and willing to cut a deal?
  • by jhealy1024 ( 234388 ) on Tuesday August 31, 2004 @04:23PM (#10122128)
    Sorry to miss the first three hours of comments, but I was dealing with some network disasters here. I'll try to clarify a few things:

    1) I'm not trying to get away from FM just because I'm a DB snob; I know FM7 will scale better than FM6 and will generally do away with the major limitations we have right now. I also know there's a FM6->FM7 conversion tool, but our databases are pretty zany, and all the experts we've talked to have recommended re-structuring the data. That's why we're moving off of FM6.

    2) As for why I want to go to FOSS, it's so I can get to the data for other applications without having to export it to TDV or XML and massage it. FM does a great job of holding all our data and making it easy to enter, change, and view. Alas, that doesn't help me for my LDAP database (which needs to be kept in sync), library patrons catalog, and other network-related user information systems. Hence, if it were possible to use an open (e.g., SQL) backend with FM's great front end, I'd be happy.

    3) I know FM has a JDBC/ODBC feature to allow external queries, but it doesn't support many facets of SQL (doh), and it doesn't currently work with the Mac version of FM7 (crap -- we're an all-mac shop). Hence another reason why I'd like to keep the backend open; I'm not waiting on FileMaker to "get around" to implementing key features on the Mac.

    4) UI is key, however. We have about 20 people who enter data regularly, and they aren't DB admins, so it needs to be simple and painless to enter, search, and report on data. To support that level of user-friendliness would be difficult to acheive in a custom web-based solution. Hence, any pointers on hooking up FM's great UI to a FOSS DB would be great.

    5) I have several years of Java, Perl, and PHP programming experience, so I could code this myself, and I fully understand the difficulties of doing so. That's why I was hoping for an off-the-shelf solution; my school simply doesn't have the budget to have me do it, nor to pay someone else to do it.

    Thanks for all the feedback so far; I'll post more later.
  • Try Smalltalk (Score:4, Interesting)

    by chris_sawtell ( 10326 ) on Tuesday August 31, 2004 @06:58PM (#10123600) Journal
    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.

No problem is so large it can't be fit in somewhere.