Replacing FileMaker with Free Software? 445
Posted
by
Cliff
from the s/proprietary/open-source/ dept.
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?"
Filemaker Pro Migration software (Score:5, Informative)
Re:Filemaker Pro Migration software (Score:2, Informative)
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:Filemaker Pro Migration software (Score:3, Informative)
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:Filemaker Pro Migration software (Score:4, Informative)
Re:Filemaker Pro Migration software (Score:3, Informative)
Other GUI clients in the pgSQL FAQ [postgresql.org].
Re:Filemaker Pro Migration software (Score:3, Informative)
Re:Filemaker Pro Migration software (Score:4, Funny)
There is also no Microsoft Access available for the Macintosh platform.
Check Out Alpha Software (Score:3, Informative)
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.
Recode for Filemaker 7 (Score:5, Informative)
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.
Re:Recode for Filemaker 7 (Score:4, Insightful)
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.
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:Recode for Filemaker 7 (Score:3, Insightful)
http://cocoamysql.sourceforge.net/ (Score:2, Informative)
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:http://cocoamysql.sourceforge.net/ (Score:5, Informative)
Others have recommended web-based solutions wth PHP, which are okay, but are difficult to maintain for the non-PHP literate.
Perhaps something like Rekall [thekompany.com] from theKompany would do it? It's not free, but it's a lot less expensive than most of the commercial front ends out there. It supports MySQL, is multi-platform, and has forms and front end scripting (using Python I believe).
Re:http://cocoamysql.sourceforge.net/ (Score:4, Informative)
http://www.rekallrevealed.org/toplevel/getting/sou
Re:http://cocoamysql.sourceforge.net/ (Score:5, Informative)
Re:http://cocoamysql.sourceforge.net/ (Score:4, Informative)
I think there's something here that is escaping most of the/. readers. Filemaker has a nice GUI for creating applications - RAD type functionality. We're not talking about a GUI to manage a mysql database. I'd like to be able to create an application that uses a database backend quickly. Something like Oracle Forms & Reports of old, or Access, or ??? Think "glade" + "mysql/postgresql" + perl's report writing
I've been looking for something like this in the OSS world for years, and in that time, like the author of the article, could have written one.
There's an old saying... (Score:5, Insightful)
Re:There's an old saying... (Score:5, Insightful)
Re:There's an old saying... (Score:5, Informative)
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)
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:There's an old saying... (Score:5, Informative)
Uh did you miss where he said that he was getting lock problems? That means he's outgrown it and it is "broke."
He said "data lock-in", meaning "proprietary", not "lock" as in "data contention".
web-based (Score:3, Informative)
Re:web-based (Score:2)
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
Re:web-based (Score:2)
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 co
Re:web-based (Score:3, Interesting)
What we do in Access (Score:2, Interesting)
well... (Score:2, Insightful)
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.
Servoy (Score:4, Informative)
Re:Servoy (Score:3, Insightful)
Re:Servoy (Score:3, Informative)
FileMaker Rocks (Score:2, Interesting)
PHP/MySQL (Score:3, Interesting)
hard work, me boy! (Score:2, Funny)
You know, if you work twice as hard it will only take you 6 months to create your own homegrown solution.
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 i
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.
Possible Alternative (Score:4, Informative)
I have had good luck using MicroOLAP Database Designer for MySQL [microolap.com]. 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)
It has a nice, clean GTK interface, and uses PostgreSQL for its backend.
Good luck!
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: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
also looking for easy, open src forms layout tool (Score:5, Informative)
Re:also looking for easy, open src forms layout to (Score:3, Informative)
It's not FileMaker, but it looks pretty good, is cross platform, plays well with others, and seems to have the major features required.
From the link above:
Re:also looking for easy, open src forms layout to (Score:5, Interesting)
Stop, drop and roll (Score:4, Informative)
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)
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)
Re:Rekall Revealed GPL (Score:4, Informative)
Re:Rekall Revealed GPL (Score:3, Interesting)
Form/report design is point-and-drool, and ev
The real problem (Score:3, Informative)
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: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.
It has always been relational.... (Score:5, Informative)
If you read the linked article [filemaker.com] on FileMaker's website, it says:
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)
* 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)
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)
It's not very 'complete', but very extensible.
Look at the pretty screenshots [gnuenterprise.org].
Rekall, OOo (Score:3, Informative)
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.
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.h
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: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.
Not realistic (Score:3, Informative)
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
School Tool (Score:5, Informative)
http://www.schooltool.org/ [schooltool.org]
steveha
My suggestion (Score:4, Informative)
when there really should be:
Not to mention the "RTFS" answers in "TFM" for questions very frequently asked by beginners:
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:
(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
not quite free, but might help as a transition (Score:3, Informative)
We looked at precisely this... (Score:3, Informative)
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.
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.
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.
Similar exp (Score:3, Informative)
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)
Progress RDBMS+4GL (Score:3, Informative)
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?
Poster Clarifications (Score:5, Informative)
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)
Re:DIY (Score:2)
Comment removed (Score:5, Insightful)
Re:DIY (Score:5, Informative)
There's a couple of reasons why (and its not just the FOSS community). The first is compatibility. I won't go into all the browser compatibility issues, but its easier to create a web page that works on multiple OS's than it is to create a desktop based application. Secondly, portability. A web based application means I can work from anywhere I have an internet connection. Now that's not to say a desktop application can't do the same thing.
In my experience (even if you're developing for a standard desktop environment) web based apps can be build faster. Then of course there's the issue of upgrades. Its easier to upgrade/update a website than multiple client machines.
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:3, Informative)
Now I have a nice web interface and everybody can access it in their native platform at home or work. For that reason, I think that w
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: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 t
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 centraliz
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: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.
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.
Platform compatibility, upgrade stability. (Score:3, Informative)
We like to make web-based applications for several reasons.
1. No license fees to worry about ont he server or my clients.
2. I can control the web/database server. (I can't and don't need to control your computer.)
3. If I make my application compliant with Netscape 3.0, it WILL WORK on ALL BROWSERS.
4. I can easily design to minimize trips to the server, maximize data throughput, AND take care of concurrency issues.
5. My application will work on ALL browsers for ALL operating systems (OKAY not
Re:DIY (Score:2)
Re:DIY (Score:4, Insightful)
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: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:3, Insightful)
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:TROLL? HUH?? (Score:3, Interesting)
Troll Prophylactic: I'm proficient with FM.
Re:DIY (Score:5, Informative)
I think you've jumped into a few really bad assumptions on this one.
First, you obviously missed the part about not taking a year off to hand code it.
Second, is MySQL and PHP always the best solution to a problem? I find it useful, but for someone who is trying to get performance out of a server, I seriously doubt that MySQL + PHP is going to be the right answer. I've found the work I have done on a HTML::Mason web server to be easily 10 times faster than it's PHP counterpart.
Third, I don't know much about the project, but I think the question was in regards to the RDMS and not the web pages themselves. I am going to assume that most of the work here is in the database structure.
If this is the case, then even a hand migration shouldn't be that difficult to do. All you have to do is write the scripts to create the tables based on their current definition and procede to dump/load the data. It would be well worth it to develop scripts to do all of this and test them out so that you can migrate the entire back end in one shot.
I don't have an answer to a easy print interface, but I can venture some guesses on what might work. OpenOffice or StarOffice has some kind of ODBC connectivity and maybe that can be capitalized with it's capabilities. Alternatively, and maybe lastly, perl has some printing capabilities that would make for somewhat simple reports but at very high speed.
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.