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?"
What we do in Access (Score:2, Interesting)
FileMaker Rocks (Score:2, Interesting)
PHP/MySQL (Score:3, Interesting)
Re:DIY (Score:1, Interesting)
I've only been using MySQL for about a month from first downloading it, and have been quite impressed. Learn a system like this, and you'll have a great long-term solution. There are quite a few GUI based tools to make administration of MySQL relatively painless, but don't expect that you won't need to read up some.
Re:hard work, me boy! (Score:3, Interesting)
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 (Score:4, Interesting)
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.
Re:Access (Score:1, Interesting)
Re:Servoy (Score:1, Interesting)
Knoda (Score:5, Interesting)
* 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 (Score:2, Interesting)
Re:web-based (Score:3, Interesting)
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.
Gnu Enterprise (Score:3, Interesting)
It's not very 'complete', but very extensible.
Look at the pretty screenshots [gnuenterprise.org].
Re:take a year off vs. pay for FM7 ?!?! (Score:5, Interesting)
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.
Re:DIY (Score:2, Interesting)
How many people make a web front end so it is "Compatible", only to design it with IE6 and Active-X necessary?
Please quit pissing down my back and telling me it is rain. I know that is why they say they do it, but it doesn't make it any more cross compatible, and no one really cares about cross compatibility anyway.
Mot people, PHB's and developers alike, are more than willing to give a big raspberry to anyone not on their platform.
The parent to your post has a point. For usability, just go with a desktop app. If you want to support multiple OS's and have usability, port the product.
For anything non-trivial, having a usable product on multiple OSes is cheaper to port a C program with a OS library than make some kludgey CGI hack of a web product.
Filemaker (Score:1, Interesting)
Re:DIY (Score:2, Interesting)
A great learning experience for them, and free labor for you.
Re:DIY (Score:2, Interesting)
What's more, you as the developer (or anyone with privileges) can make changes to the interface on the fly, and as soon as you commit them, everyone else sees them, without even having to restart the app, let alone download something.
Further, the idea that all web apps have the same interface is wishful thinking. For example, compare the interfaces for Expedia and Travelocity, which both do the same thing. They're as different as can be.
Re:also looking for easy, open src forms layout to (Score:2, Interesting)
Why Access? (Score:2, Interesting)
Re:DIY (Score:2, Interesting)
What it does do *VERY WELL* is allow a non-programmer to build responsive and easy to use interfaces that can access a networked database (or set of databases).
The original poster doesn't seem to explicitely say one way or another but the context *suggests* he's using FileMaker with a client rather than a web based UI.
I'm not going to get into a long post but suffice it to say that having used systems similar to the sort the original poster describes, replacing them with a web based UI will create an inferior user experience.
While I don't have the knowledge to suggest one, the poster needs an FOSS solution for easily and rapidly building a responsive client-side GUI application for a FOSS database. If they build a bunch of web forms to solve this they will *piss off their users*. Pissing off users will not advance the cause of FOSS software or our poster's career.
- AC
Re:DIY (Score:3, Interesting)
- client-server database applications (i.e. "database on ONE SERVER"...) are possible w/o using a web browser as the platform for the client, but instead using an app native to the client OS. this is not only how Filemaker does it (yes, FM can work w/ remote dbs), it's the standard way of doing this sort of thing
- "They don't have to figure out whatever GUI you develop for the tool." - huh? while certain functionalities are always clear on the web, those tend to relate to navigation, not inputting and updating data. once an application gets specific (i.e. worthwhile) enough, it's doubtful that it'll look muhc like a common web-page asides from some header navigation. using the web as a dev. platform is only helpful towards GUI design when the app's GUI shares a lot w/ the web browser GUI.
- "one easy interface that everyone can reach and access make it easier to maintain" - this, I almost agree with. I removed "easy" as I've found that making web app interfaces "easy" often requires more work that would be necessary in a native app (either lots of design work or lots of development work to paper over browser diffs).
What's wrong with what you've got? (Score:4, Interesting)
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 [google.com] - once you get stuff into PHP there's almost no limit to what you can do.
Re:Filemaker Pro Migration software (Score:3, Interesting)
It's just like compiling a program in visual studio. You can't redistribute visual studio, but you can distribute the programs you create with it.
-Adam
Re:web-based (Score:3, Interesting)
Re:DIY (Score:3, Interesting)
I personaly find some web pages, and web applications nearly imposible to navigate through, lat alone for the Avg joe who double clicks everything on the web.
But I aggree about everything else about having a centralized place for the "application".
Am I the only one who wants to see java take the place of many things here? One app, hosted on centralized web server, and full features that websites can not mimic.
Adapt your users and processes to existing s/w (Score:3, Interesting)
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.
Having it all... (Score:1, Interesting)
In this case, having it all entails migrating to a solution that replicates/improves upon the existing solution without having to do a lot of programming.
Forget it. It'll never happen. If you migrate out of FM, you WILL have a ton of coding to do to replicate the existing functionality, and you'll be employing a hodgepodge of technologies that may work, but will take time to develop, learn, troubleshoot, and maintain. (Take your 6 mos and double it...) Plus you might not be able to come close to the things fm does really well: interface and printing.
Although FM7 is different, many solutions can be imported with minimal changes. It might make some sense to recode your system from the ground up, but you might be able to import with some minor mods. (If you have a number of FM Pro licenses, use that to your advantage-- get your FM sales rep involved and get them do some work for you.)
There are advantages and disadvantages to both sticking with FileMaker or migrating to SQL. (Migrating out MIGHT be the best choice for you...) However, certainly look before you leap, and compare the advantages/disadvantages of both systems before deciding.
Re:TROLL? HUH?? (Score:3, Interesting)
Troll Prophylactic: I'm proficient with FM.
Re:DIY (Score:3, Interesting)
Apparently, mySQLcc ("control center") is no longer under development, but I think it's pretty nice as is. There are two new projects replacing it that I haven't checked out yet.
It is still NOT a FileMaker like UI builder, though, but it does let you manage a database with a nice front end GUI.
Re:DIY (Score:2, Interesting)
While most of my time I spend solving networking problems & coding webinterfaces I'd like to congratulate the parent poster on his keen remark. My rant isn't on the FOSS community, but the webdevelopment trend in general.
I _REALLY_ don't know. I've been irritated by it as well as a developer. When I started out working for the company I currently work for I thought "OK, a few webbased projects every now and then, easy enough.". Three years later, most of the coding I do are still webbased projects.
The funny thing about it is, most people don't care and don't know the difference between a browser and a client anyway. Of all the clients I've happily provided with a webinterface, there has been only one that said "This just isn't working for me".
Perhaps we are seeing so much webapps because they are so easy to develop compared to "classic" GUI apps. Even if we weren't to resort to using C, C++ or java, we'd still be dealing with event handlers, signal handlers or signals and slots (whatever rocks your world). Webapplications don't have that, and simply have input through parameters or STDIN, and output through STDOUT in a language that every geek and his trained monkey speak fluently.
By the time you've done this for a year, you've developed some sort of toolkit that allows you to easily make HTML tables from an SQL query, and webdevelopment just became 10 times faster. And that's the kind of thing the people upstairs like to see: a codemonkey that spits out code in days in a system nobody can migrate away from easily because the toolkit/perl-module/php-include is hidden safely on the machine where the customer can't access it.
Webmonkeys in the long run can be x times more efficient than real programmers, and not just because of the fact that it's easier and doesn't require the knowledge of pointers, but the fact that once you have the toolkit you will hardly ever have to write anything new. HTML 4.01 is still widely in use and that won't change very soon (but still, it's very little work to switch over if you use clean HTML), SQL won't change very soon either (but sometimes you have to use another DB and do some late night coding on your DBH-layer), and the rest is just a few lines of perl code (or PHP, or whatever...).
What the customer gets is an application that does what he needed (some addressbook, some view over statistical data, something or other), developed in a small amount of time, accessible over the internet (hopefully in a secure fashion), and the joy of it all (what interest them most) is that it is cheaper than the solution with the GUI client.
By all means, this is not a rant against the use of GUI applications. Sometimes I'd give real money to escape the boredom and lack of features of HTML and cousins. I'd love to spend some time hacking together something really nifty in C++ with QT, or whatever widget set I was in the mood for that day. But when I start thinking that I'm going to have to explain that the code for a GUI app is horribly more complex to maintain than the couple of SQL statements and HTML templates to my manager, I know I'll have to explain my toolkit to the poor sod who'll take over my work once I'm fired.
So, perhaps that is the reason why I have to do so many webprojects. Not because I'm good at it, but I've made a tool that only I and one other know the full internals of, and we both became fast developers because of it. Maybe it is because our customers can't afford to send me in to C/C++/Java heaven for the next 3 to 6 months, or maybe because the GUI development goes to all .NET programmers these days (which sa
Re:also looking for easy, open src forms layout to (Score:5, Interesting)
WebObjects Direct2Web (Score:1, Interesting)
Demo developer version available from connect.apple.com [apple.com] with a free ADC account.
Direct2Web is one of the easiest ways to do your RAD and get clients or yourself up and running.
RealBasic (Score:2, Interesting)
Re:Recode for Filemaker 7 (Score:4, Interesting)
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:Rekall Revealed GPL (Score:3, Interesting)
Form/report design is point-and-drool, and even includes wizards for fast form- and report creation. It allows forms and report templates to be stored in the database itself, so only a small file containing db login information etc. needs to be installed along with the client software. You can script everything with Python, or use macros if you are unfamiliar with Python.
It's an excellent RAD tool for database apps that require little to no programming experience, and it comes with plugins for a lot of databases (including MySQL, Postgres and ODBC). Some of the DB plugins are sold separately for the binary W32 version. As for a Mac version, there are currently no binaries available as far as I know. I do not own a mac, so I'm not sure if it compiles cleanly on MacOS. Apart from the DB libraries I think it only depends on QT and Python though, so I can't see why it shouldn't work.
Re:DIY (Score:1, Interesting)
We went with Swing for our last project since it was supported on all the platforms we needed to target (OSX, Linux, and Windows), thinking to ourselves how clever we were for "leveraging" such a powerful tool. That was until our client started pointing out dozens of tiny visual glitches (line wrapping cutting off characters, Layouts that didn't perform identically on all platforms, etc.). It gets worse when using the platform native LnF wrappers.
Not to mention internationalization errors, the cause of which we STILL can't track down.
As a direct result of the pain of Swing, we're buying a multi-platform Qt license.
Re:DIY (Score:4, Interesting)
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 (Score:4, Interesting)
Export from FileMaker, Load into another backend (Score:2, Interesting)
Speaking as someone who is working on a similar product, I would suggest this:
Yes this means having your data in two seperate places, but it also means you get to keep the frontend capabilities of FileMaker and if and you don't have to do any major recoding (other than a couple pretty simple shell scripts).
If you want to go super fancy and not have to export the files manually, make use of the SOAP capabilities in FileMaker Server Advanced (when it comes out, which should be soon -- Server might do this, but I'm not sure). The script could use a web service to check for any changes in the data and then procede to sync.