Slashdot Mirror
Replacing FileMaker with Free Software?
jhealy1024 asks: "I'm looking for a way to replace our FileMaker DB solution with an open-source RDBMS. Problem is, FileMaker's GUI and report design tools are pretty darn good, and I can't find a suitable replacement. Anybody out there have a solution that doesn't require me to take a year off to hand-code a replacement solution?"
"I'm the netadmin for a small private school. Since we're Mac-based, we've grown up storing all our data in FileMaker, including student information, grades, class assignments, gifts, inventory tracking, and just about anything else you can think of.
FileMaker is coming out with version 7, which is going to require us to tear all our databases to pieces and build them up again from scratch. While the new FileMaker is an improvement, it's still a toy as far as "real" databases go. (The latest update just introduced relational tables, for example). Also, data lock-in is becoming a problem; I'd like to have access to all our data from non-FileMaker interfaces (to populate our LDAP directory, for example). While we can work an export from FileMaker, it would be much better if the data were available in an open, standard database instead.
I figure, so long as we're rebuilding everything from scratch for version 7, why not use a "real" RDBMS (no flames about which, please). Problem is, FileMaker does two things very well:
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 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?"
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.
You are in error. No-one is screaming. Thank you for your cooperation.
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.
http://cocoamysql.sourceforge.net/
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.
Javascript + Nintendo DSi = DSiCade
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.
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.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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 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. www.servoy.com
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.
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.
Dedicated Cthulhu Cultist since 4523 BC.
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.
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.
"You say self-important egomaniac like its a bad thing?!?"
How about Glom?
It has a nice, clean GTK interface, and uses PostgreSQL for its backend.
Good luck!
The Free desktop that Just Works
Why is that everyone in the FOSS community always wants EVERYTHING to be a web-based application.
Is it so hard to imagine that some people really want application state, a really responsive UI, the ability to work with data without many round-trips to the server, etc?
Web-apps are nice, but geez, they aren't the frigging holy grail!
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?
-Lod
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.
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.
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 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 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.
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
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.
If you read the linked article 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.
Drill baby drill - on Mars
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.
"The truth shall make ye fret" -- The Truth, Terry Pratchett
Gnu Enterprise might be just what you need.
It's not very 'complete', but very extensible.
Look at the pretty screenshots.
The path I walk alone is endlessly long.
30 minutes by bike, 15 by bus.
They're looking for a new Web-based replacement for their existing Web-based application that was built in FileMaker--a web design product.
The grandparent is not suggesting replacing a desktop solution with a Web-based solution,
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.
Well for one, if the tool is data driven, it just makes more sense to have the database on ONE SERVER rather than as part of an app that you have to store on a million different boxes and then update constantly. Second, one easy interface that everyone can reach and access make it easier to maintain.
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.
This is my sig. There are many like it but this one is mine.
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.
US Democracy:The best person for the job (among These pre-selected choices...)
Our school Heritage Christian Academy (heritageweb.org) has been using SchoolMinder for several years. It was nice but I think we've outgrown it. We're currently installing PowerSchool, an Apple product. Mail me off-list and I can get you more info. Yes, I thought about writing our own (with PHP and Postgres, no flames please), but the number of tables, queries, dialogs, reports etc was quickly growing to be beyond what one person could support. It's not as simple as some would think when you add in grading, attendance, transcripts, class scheduling... for 500 students.
Absolutely.
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.
I don't need no instructions to know how to rock!!!!
I am migrating some applications that I have created in Filemaker to MySQL/PHP, because of the increased flexibility. Reporting has been a problem, but DataVision (datavision.sourceforge.net) is an excellent and easy to use tool. Runs in java, (1.4) so it works everywhere except MacOS 9. For that platform, I use an early version of Elixir Reports (www.elixirtech.com) Elixir Reports is not free and buggy, but usable.
http://www.rekallrevealed.org/o rg/
http://www.knoda.
Both free and both viable options imho.
Also keep an eye out for kexi:
http://www.kexi-project.org/
This looks like it will be really impressive. However, as it is still in early beta this probably isn't something for real world usage yet.
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:
.net "way". Alice has to learn quite a lot to get there, though.
h tmlPythonCard, which is looking very nice: Python is a very newbie friendly language. If you use this, then ReportLab (http://www.reportlab.org/) might be a good choice for reporting tools.
Alice is an expert in some area of business. She can even wrap her head around simple databases. How can she write database apps without having to call Bob, the resident Unix hacker who doesn't want to waste his time coding simple data entry screens.
What tools can Alice use? Open Office is workable now, and although pretty clumsy, compares to the VB
There's http://pythoncard.sourceforge.net/samples/custdb.
There's Rekall, I've not used it at all, although it looks pretty good.
And then there is GNU Enterprise http://gnue.org/. 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.
School Tool is a system specifically designed for running a school. It's written in Python, and it's free, open-source software.
http://www.schooltool.org/
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
How many people really give a shit about multiple OSes? Really.
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.
Why is that everyone in the FOSS community always wants EVERYTHING to be a web-based application.
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.
Even better than doing it yourself. Work with a professor and come up with a new class syllabus. Have the students create the database and gui (MySQL + PHP).
A great learning experience for them, and free labor for you.
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
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
With FileMaker, the database _is_ on the server. So is the application design and interface.
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.
Great point! I would even extend the original post to say is there ANY other cross platform tool that's quick and easy to update that compares to Filemaker? We also need to have control of printing, and it can't be a web interface. We did a study on going to a web interface, and those seconds end up. If we switched our system over to a web based interface we were looking at almost 5 hours per week of lost productivity just because we had to hit submit so many times, and wait for the screen to draw, not to mention lost data, more complicated list views, etc.
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.
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.
Access is horribly slow for any real database usage (i.e. more than a few dozen people). Before you mod me down as flamebait, you should realize the company I work for uses ODBC for all of the database needs, and uses ASP/JSP as the interface. The performance sucks. Get anything more than 20-30 people using it at once and the server comes to a crawl. FYI, the setup is used about 70% for data retrieval, and about 30% for data entry. And, for some reason the coders decided it would be good to use IBM WebSphere for the new interface, but still keep the ODBC server.
You obviously have no clue what you are talking about.
FileMaker Pro has been relationnal since version 3. Even worse, the migration from any 3.X, 4.X, 5.X, 6.X to version 7 is handled by FileMaker itself. You even have a 190 pages document describing all the changes and the tweak needed in case of something goes wrong.
I'm not saying the problem is painless, it all depends on the level on complexity you have in your current system. I just migrated a _very_ complex solution (80 tables, over 120 links, 1900 fields, 600 Scripts) to version 7 from 5.5. It's all documented on one A4 sheet.
DUH.
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 the Lynx browser).
6. No license fees to worry about ont he server or my clients.
The list goes on...
You said "No license fees twice!"
I LIKE no license fees.
I live the greatest adventure anyone could wish for. - Tosk the Hunted
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
FileMaker is *NOT* a web design product. It offers some (profoundly lame IMO) web 'front-end authoring' functionality but it's NOT a web-centric product.
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
My personal preference is also for web-based apps... however, you're not really answering his question, for the following reasons:
- 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).
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.
My English teacher once told me that two positives don't make a negative. Two words for her: Yeah, right.
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 ).
"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."
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.
The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
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.
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.
For database driven apps, it's pretty much the best way to go.
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!
Hey freaks: now you're ju
Well, I pitched a similar project to a client of mine, and one of my key points was that making changes to his FileMaker database/app is more labor intensive than modifying a similar php+sql setup. Might take time to set up, but if changes are needed frequently (as in my case), then you'll be money ahead in the long run.
Troll Prophylactic: I'm proficient with FM.
Literalism isn't a form of humor, it's you being irritating.
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.
Go to the mysql download page and look for graphical clients.
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.
Stupid sexy Flanders.
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
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.
Not if you go to a java type solution like oracle did with their Application Server. Very nice and very fast. Not free but there might be something out there like Oracle Forms?
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.
Like the poster I replied to, these types of comments typically don't offer anything more of use than pointing out what we all would agree is abvious... sure the asker could go off and program their own. If that were a viable option, then they probably wouldn't have asked slashdot. In fact, this asker even said that he didn't want to take that route.
Again, my primary gripe is that the poster didn't offer anything else to support this suggestion. It was wasted keystrokes without saying something like "Check out Hotscripts or the PHP Resource Index for a good place to start. In fact, check out FX.php for something that will help you migrate from Filemaker to PHP." Answering "just do it in PHP/MySQL" and leaving it at that kills the thread usually without offering anything intelligent. I suggested (though I admit I was a bit crass) that posters like that provide more info and produce an actual constructive answer instead of an aloof and castrated suggestion that is offered far to often in ask slashdot replies. I've had my fill of them and finally felt I had to say something.
US Democracy:The best person for the job (among These pre-selected choices...)
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?
My guess is that you're referring to the fact that FMP 7 introduced multiple tables per file. FileMaker has been a relational database since version 3, but prior to 7 each "table" was a separate file.
Those who can't, post on Slashdot.
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.
Putting aside the issue of whether or not you really need to upgrade, which others have addressed, the RAD tool that does what you want is RealBasic. It's not OSS or free-beer free, but you only asked for compatibility with free stuff. Caveat: I only goofed around with the demo, but I've never heard anything but good stuff about RealBasic.
Holy cow, thanks, I'm going to warn Yahoo that they've been using a toy all these years!
Well in education you generally have to deal with PC and Mac computers. In my case I have a little bit of Linux as well. I care about cross platform. I have been building web-based front ends for my database apps for the past few years for this exact reason. Our PR person is Mac but our calendar application was in Access. We had to give her a PC just so that she could use it.
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 web interfaces are best for database apps as they don't require much more than data formatting and validation.
Dissolve... Resolve... Evolve...
1) No, PostgreSQL doesn't require you run it as root. The install file (you did read it, right?) tells you to create a postgres user to own all the PostgreSQL files.
You have to start it as root, so that it can take it's port and change userid to postgres, but it doesn't run as root - do a
ps -axw | grep post
on a machine with PostgreSQL, and you'll see what I mean.
2) No, you don't need to reboot the whole machine to alter tables. If you read the documentation, you'll find out how to do that from the psql client.
And even if you do need to restart PostgreSQL, you can restart just PostgreSQL - this is unix software, not Microsoft crapware.
It's not free, but it is extremely good, and cheap compared to FileMaker. It's java based, so runs on Win/Mac/Lin/BSD/Solaris... though we're just using it on linux.
It's a Dutch product called Servoy. There's a demo available, a very helpful community (the CEO, Jan Aleman (jaleman) posts a lot), and the manuals and other materials are also available online for free. It comes with a Sybase iAnywhere licence out of the box (if it came in a box) but uses JDBC, and has PostgreSQL and MySQL support right off.
As you'll find out when you read the site, there is no file format; the solution is kept in a database. It also uses javascript as it's scripting language.
All in all, a very nifty product. And I'm not just saying that because we spent $6k on licences (previously we spent $3k on FMPro 5 licences, which were never used due to the product being inferior), I really do love working with it.
Web programming is NOT client-server programming, because you do not program the client. Instead, you issue a set client a series of cues on how it should interact with your server, which handles data processing as well as flow control.
The main difference between client-server programming and web programming is the role the client plays. A dumb client like a web browser responds in one way which is pre-ordained, and thus is unreliable in verifying data and presenting the user with information. The role of formatting and display is the responsibility of the server, and this cuts into the responsiveness of the UI. A smart client KNOWS what data it's going to receive, knows how to display it, and knows what data it's going to send back. This knowledge allows it to perform important pre-processing before the server is even contacted, which means less crosstalk, better response times and a more pleasant experience. It's also less stress on the server and if done right can mean greater supportability.
This is also discounting the fact that the web has no great way of performing many-to-many relationships, or loading information dynamically without replacing the current context. Can you imagine if every time you tried to write a bullet point in Word, the whole program closed and reopened?
As for "quick, easy changes occurring more easily:" dude, I used to be the backend programmer for a website ASP. I wrote a series of client tools to speed up what the customers considered an arduous, almost unbearable process: updating their website every morning with fresh content. Simply moving the interface from a web site (which was damned responsive, mind you) to a Java client dropped the time to load a manifest of articles from an average of 2 hours to an average of 45 minutes -- and it handled MS Word codes much better. Adopting a static Word aware client along with a Quark XPress scraping tool (try doing THAT on a fucking web page) brought it down to 15 minutes or proofreading. I don't remember smoking any crack when I did these tests, but it must have been the type of crack that gets you a nice fat raise.
Hey freaks: now you're ju
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.
Let me explain:
.NET). Yeah, all that's currently available in FMP7. ODBC, XML, and JDBC has been available in FM since version 4.1 (ODBC), 5.0 (XML/JDBC). I can only conclude you have a pre-4.0 version, and since you don't use relationships, a pre-3.0 version. Blaming a 10+ year old piece of software for the shortfalls of modern technology is being unreasonable.
"FileMaker is coming out with version 7, which is going to require us to tear all our databases to pieces and build them up again from scratch.
No, it doesn't if you don't want to. You can just convert, but you won't take advantage of more than the software performance/structure benifits, until you actually change how your databases are built.
While the new FileMaker is an improvement, it's still a toy as far as "real" databases go. (The latest update just introduced relational tables, for example)
At about this point I'm wondering what version of FMP you're using right now. It has to be pre 3.0, because that's when FileMaker went relational. Well over 10 years ago. I wouldn't consider it a toy at all. I would consider Access a toy compared to FMP7 (Not that Access sucks, quite the opposite, it's just that FMP7 has far far more capabilities than you seem to be giving it credit for)
Also, data lock-in is becoming a problem; I'd like to have access to all our data from non-FileMaker interfaces (to populate our LDAP directory, for example). While we can work an export from FileMaker, it would be much better if the data were available in an open, standard database instead.
Like ODBC? XML? JDBC? XML/XSLT (For
I'm not sure how to respond to the rest of your article. You act as if FileMaker is the worst database program in the world, and has no scaleability (Not true, filesizes are at 4+Terrabytes, with 1GB of text per field, per record, with indexing services that scale perfectly fine whether you're at 40kb, or 3.5 terrabytes worth of data.). So my only conclusion is that you just flat out don't care to learn the benifits or functionality of using all the capabilities of FileMaker. That's fine, but don't poison the slashdotters minds with your lie based propaganda.
If you really want to start learning FMP7 and what it's capable of, check out some of the tech articles on the support section of the www.filemaker.com website. They should give you the general overviews of what you're missing, and the details are in a pretty robust help system within the application (Or server disk).
First off it should be noted that you can not use ODBC, OLE, or any else besides XML to access a Filemaker database.This means that you can't integrate Filemaker with outside applications programmed in an multitude of languages without building your own wrapper or obtaining a wrapper from someone else. Some people will say hey wait I saw in the docs that it supports ODBC. Look a little further into it and you will find that the client for Filemaker supports querying ODBC mounted db's but not the other way around.
1.)Absolutely 100% wrong here. It uses ODBC (Pretty much every SQL command including table creation), JDBC, and yes, it uses DDE too. Has just upgraded to a very robust XML system, which I'll cover in a second.
The multi language thing is total BS as well. It's completely unicode compliant.
2.)For your #2, I just don't want to copy the entire text you wrote out, it's all crap. XML can be queryed from the server engine now. That pretty much defeats your entire rant there. Oh, and it's incredibly fast, especially with Web Services enabled to take advantage of caching features.
3.) THe secutiry method is about as granular as it gets now. It has external authentication, an extremely powerfull pessimistic security model, and as much of a lockdown as you can possibly wish for.
4.)Again, totally off base. It's incredibly compliant, and is ansi SQL-92 compliant as a matter of fact.
I'm still trying to figure out what the point of your post was other than showing how little you truly know about FileMaker and spreading your single minded cynacism to uninformed readers. Get some facts, research the product you're bitching about.
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 application at the speed of whim, so you can figure out what you want while in design mode. Do you really want to tie up a developer in this cycle? And please resist saying "hey, these business users need to figure out what they want first!". Sorry, not realistic. You use a rapid prototyping environment like MS Access / Filemaker because you want something *now*.
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.
Any authorized user can access your Web database thanks to the built-in Web Application Server.
Create powerful applications without having to write tedious and intricate code.
Step-by-step genies assist in creating scripts without knowledge of programming.
We give you the tools to build sophisticated applications quickly and easily.
I used it a few years back, and was impressed then. I think I may go ahead and get the latest version. There is a free trial.
"It is a greater offense to steal men's labor, than their clothes"
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.
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:
"The future's good and the present is nothing to sneeze at." - Roblimo's last
You (and a lot of the other "database lite" projects) completely miss the point of an application like FileMaker or MSAccess.
1) All of the data, queries and reports need to be stored in a single file, or a single folder. Even if that limits you to 2GB database sizes.
2) It should be easy to move that database from machine to machine using Windows Explorer. Backup copies should be as simple as closing the application, and dragging the file to the CD-writer.
3) Integrated queries and reports, stored in the database file along with the data. Bonus points if things work well on the web just by putting the database file up on a server and telling the web-engine portion where to find it.
Formats like MSAccess MDB files are easy for the user to manipulate. Very similar to working with an Excel file (tables are like tabs). No need to babysit their own personal copy of a SQL engine, or beg a DB admin to create a new field / table / database.
I'm semi-hopeful that now that IBM has released their java mini-database engine, we might see progress.
Wolde you bothe eate your cake, and have your cake?
http://protege.stanford.edu/
Use Protege-2000. It's functionality eclipses that of FM Pro. It is well-tested and in wide deployment. It is trivial to make UI plugins and other kinds of deep additions in Java, but hardly ever necessary. It is free and open source. It has a paid team of developer that fix problems proptly and provide support.
And it supports any SQL database as a backend, and inserts a "semantic data modeling" layer in between the DB and UI that allows you to do very sophisticated things in a common sense, non-db-nerd way.