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.
Totally... in fact, depending on what you are doing, there are loads of MySQL+PHP projects out there that may already fit your needs.
This is my sig. There are many like it but this one is mine.
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?!?"
I've only been using MySQL for about a month from first downloading it, and have been quite impressed. Learn a system like this, and you'll have a great long-term solution. There are quite a few GUI based tools to make administration of MySQL relatively painless, but don't expect that you won't need to read up some.
How about Glom?
It has a nice, clean GTK interface, and uses PostgreSQL for its backend.
Good luck!
The Free desktop that Just Works
Amen. My Help Desk needed a operations monitoring/backup tape/outage tracking solution. I rolled it myself. The outage reports are a bit homely, but printable, and the PHB's are happy.
You are not the customer.
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.
Access Professional also comes bundled with a tool to create a stand-alone executable for use with the databases. You don't have to pay for licensing on this executable. The database design also cannot be modified using it, and for a deployment situation that's probably a good thing.
We're working with a client who has set up a pretty good system using Filemaker. This works great until they want to communicate with other databases (like MS SQL, MySQL etc) - which works, but is a pain.
FMP is a good product though, and you should really think twice about moving from the technology. Do you really have to?
If you really have to, I would recommend using PostgreSQL or another database which uses more of the SQL-standard than MySQL. Of course it is easy to create some kind of solution with PHP/MySQL, but consider other technologies too. And especially - can other technologies offer the ease of use for development and user that FMP do? If so, and you see that you have a real need for migration - go ahead. But plan ahead, because some of the things which is FMP's strengths could be hard to do with other technologies.
Note that I don't really like FMP, just recognizes that it - at times, is a good technology.
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.
You would also be better served say away from MySQL... its nice for quick dirty stuff... like blogs and what not. But if for any intensive DB needs, and your not locked in to MySQL then STAY A WAY!
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.
It may be a while before a project is available that can replace FileMaker or Access.
= 9J =
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
They are, however, easy. The reason they're being suggested is because that's what's out there and available for free.
A while back, Rekall - in conjunction with a sql database - looked like a potential open-source replacement for FileMaker and Access.
Has anyone here successfully ported a FMP database to Rekall + {MySQL|PostgreSQL|etc}?
Ref: http://www.rekallrevealed.org/
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.
I use OpenOffice Databse User Tools. It doesn't have all the great features of FileMaker, but serves as a pretty good alternative to that and MS Access. I think the Form AutoPilot and Report AutoPilot address the problems you're facing.
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.
Glom looks like a good start, but it is not mature enough for critical systems. The biggest problems that I have had with Filemaker is that it cannot easily transfer Binary Large Objects, "BLOBs", to other databases. Think school ID photo. For this you need to use visual basic or other tools. Good luck
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.
I think you'd be best off writing your own stuff. PostgreSQL + Perl
There, I fixed it for you.
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.
filemaker databases are often used for making back-office type software, to run a small business. this is really the ideal place for a web-app, for a couple reasons. first, you can access it from pretty much any computer. it's also less work for the IT guy, as you don't need to worry about making sure everyone has the latest version of the client software -- you update it on the server, and that's it.
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.
Ironically I am sitting on the conference floor of DevCon in Phoenix. For those of you who don't know that is the FileMaker conference. I am afraid that based on your comments and critiques you have not actually understood just how much has imporved in 7. It is FAR from a mere upgrade and constitutes a major leap forward. If you wish to convert your solution simply purchase FMROBOT. this will move up your solution with some minor touch ups. As far as lack of xDBC and SQL type connectivity, that has been addressed with Server7advanced. As far as the cost compared to a free open source solution is concerned. Not only is FMP not cost prohibitive but you will pay for the alternative 100 fold in dev time.
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.
There is a way to display your filemaker info out on a php page. The php library is called FX and it is a wonderful tool that will allow you to code in selects on a filemaker db along w/ selects on other dbs...
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.
It looks to me (but I have no experience with it) that SQLite is part of an excellent replacement for Access, FileMaker, dBase, and FoxPro.
From the look of the web site, SQLite is VERY impressive. Now we need a GUI form designer.
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.
Agata is a PHP-GTK report generation tool, with versions available for Linux and Windows. It still doesn't come close to being easy to use for non-technical (or even technical) users - unlike FileMaker. There is an API available, so after you've spent 2 months replacing all your Filemaker forms with PHP pages, it will only take another few weeks to convert your current reports.
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 think you're on the right track with this. Yes, it will take time and effort to build the FileMaker to SQL bridge. However, once that's in place, you've got your raw SQL access for the other apps you mentioned. Plus, you can start turning out reports directly from SQL, and create apps to enter data directly to SQL as needed. If you make them prettier/faster/easier than the "native" FileMaker interfaces, people will start using them instead. Before you know it, you've weaned everyone!
Short-term, you may or may not need the new FileMaker licenses (can you stick with the current version?), you will need the SQL plugin licenses, and you'll have to spend some time coding the SQL/FileMaker bridge.
Long-term, you've gained the raw DB access you need, provided an alternate means of both data entry and access, and released your data from proprietary lockin.
1) Put together your project plan and budget,
2) Compute the project's ROI,
3) Run it all by the comptroller,
4) ???
5) Profit!
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.
No, silly, you keep the database on one server and give out little client apps.
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.
Yes they do, and you don't have any standard UI guidelines to follow, so it can be as ugly as you want!
Depending on what you are really looking for and the size of your school there are some good web based one is called Sips it runs from PostgreSQL and can run on Winbloze, MacOSX, Redhat 7 or higher.. might be worth looking into since you are talking about redoing your current Dbase from the ground up.. I'm sure the company that just bought it (Pearson) may even help convert the data for you.
"Imagination is more important than knowledge" -- Albert Einstein
You should have waited until the filemaker developer conference is over (aug 29-sept 1) before submitting the story It would have made for much more interesting slashdotting and probably some more informed opinions as the whole slew of FM/database geeks are away from slashdot.
I have been in the same boat many a time. I remember one time some brainchild tried rolling out an Access app across three sites spread out across the country. He kept on saying, "It seems fast to me. What are you guys complaining about??" Not realizing he was looking at the LAN end of the app. The rest of us were many a hop away.
Then this genius figured that if the WAN response time for these huge chunks of data was too slow perhaps he could force some Access database replication scheme. Nice try.
And the people who put these projects together sometime fail to grasp the difference between OLE DB, ODBC, native SQL, etc. connection methods. They think because ODBC is so easy it must be the best, fastest connection method. Right!
I would place Access in the same realm as some small homegrown app that relies on an MSDE back-end. Take it beyond a handful of concurrent users and you're out of your realm.
I'm the IT Manager at a small company. I do a lot of custom PHP/MySQL programming. Another person does FileMaker development. What I've found is that PHP/MySQL is superior in almost every way. The biggest problem with FileMaker is that it's a fat client architecture. We have 180MB of contact information that takes a long time to move to the client BEFORE a search/filter is even performed. The server sends EVERYTHING to the client no matter what subset you're interested in - the client does almost all the processing. Of course, this annoys the heck out of users, especially those outside our network (making it pretty much unusable outside our network). FileMaker and PHP both require a fair amount of proprietary knowledge to get them going. My opintion: toss out FileMaker until it's a true SQL-enabled RDBMS. Right now I think it's garbage. PHP/MySQL isn't perfect, but it's far superior.
The state of graphical FOSS being what it is, I think there's a giant hardon for web-based solutions because the browsers are the most useable FOSS gui apps.... and because, ultimately, things are slowly drifting back to the mainframe model. All the data on the server, manipulated from a client/terminal.
:)
Web "terminal" frontends happen to be (bar none) the easiest to develop. Target Mozilla and suddenly just about every operating system in the world can be considered an option for data input.
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
I'd say go for Postgresql and PHP. If they are looking towards the future, and wanting a more robust RDBMS server, I believe Postgresql is a little better than MySQL....at least at this point in their respective developments.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
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
MySQL, MySQL, and more MySQL. A love affair has grown with MySQL.... but what happened to PostgreSQL?
Inherent advantages exist with using PostgreSQL: subqueries, stored procedures, cursors and views among them. A feature-rich database. Let's not forget the time one wastes running REPAIR TABLE on larger databases with non-transactional MyISAM and transaction-capable InnoDB.
A MySQL vs. PostgreSQL debate could rage forever, and I see merits in arguments against PostgreSQL, but to the matter at hand. That tool mentioned earlier in this thread is actually recommended highly by all my Database-loving friends for said purpose. I personally would prefer to write something myself, as I never feel fully comfortable with someone else's GUI view forced down my throat.
Web-based is the way to go. Using local apps for a database application is on the same stupidity level as spending months bundling a firewall with a service pack for an os that doesn't work after months of singing its praises. A properly developed web-based app for handling a database can do the same job as a local app.
The Crimson Dragon
we at the UCI computer store, wrote a java GUI system for mysql backend... it contains some stuff that might help you, should you choose java as your path. replaced out filemaker with it, and never looked back. it has one feature you might be interested in: a module to parse filemaker-exported XML and import into mysql. everything's GPL, but i dont really want to post on a slashdot thread for security reasons. drop me a line if you're interested in obtaining the source: munsonm at uci dot edu --m
there's a ton of books and web based information on this.
As a new user to MySql, what did you use and what do recommend along these lines?
thx..
Creationists are a lot like zombies. Slow, but powerful and numerous. And they all want to eat our brains.
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.
... ever consider Sybase's SQL Anywhere Studio? The suite costs $400 USD, and comes with a database engine (and other programs to help you create forms, etc.). Some alternate links here and here.
The Adaptive Server Anywhere RDBMS is rock-solid and fast, and runs under Linux. It integrates nicely with any ODBC-based (or JDBC-based) front-end application, and offers true SQL99 compliance. It also has Java support built into it, so you could actually run a web server from within the DB engine. I've been using it quite happily for a few years.
Just a thought.
I have been a sysadmin in a school myself for 3 years... hating MsWindows and all the big "problems" that come with it... dreaming of turning the school into a real playground with Linux etc... So I tried my best to solve this problem too...
There are no GUI frontends to any linux-based DB system, no matter what they tell you. MySQL has the most attempts to build one, but all of them in the alpha development stage. MySQLCC is the best (from my point of view) but still too many mistakes to make it useful for someone who is just a "user".
There are no alternatives. Sorry to say that, use Access on Mac, and you'll have a nice GUI with anything you would expect from a nice modern database.
http://www.automatiq.se
Ah, the horrors of FileMaker 5. We're currently using it to enable a WWW content manager to update the product catalog for a B2B sales site. The manager makes her changes in FileMaker, exports to flat files and then I work my Perl and Oracle magic on it to populate the production database.
The only problem with this setup is that the developer that originally wrote the FileMaker database left the company and he provided absolutely zero documentation for the rest of us to follow. Trying to figure out just what each action does (I forget the name of the menu item) is next to impossible and the workflow for creating a new action is completely non-intuitive and cumbersome. I've also had weird problems where type declarations regarding exported data would cause certain information to just not make it into the resulting flat files. Just using the database that's been setup is easy as pie, it's when you start trying to make changes that things get confusing.
Our migration solution was to write a proper 3-tier web based application that housed the product data. The developer in charge of this project happened to use C# and .Net, but it should be a simple matter to create something with Apache, CGI, Perl and a RDBMS like mySQL or PostgreSQL.
I know you were looking for a different solution, but for us, a rewrite was the way to go.
It is an issue. SQLite is much easier to install and begin using than the big RDBMs. The small database on each computer market is where dBase, FoxPro, Access, and FileMaker compete. PostgeSQL is for enterprises with many clients.
I agree, form design is the most important issue.
A few suggestion that aren't exactly free as in beer - as the development environments are commercial. But they'll let you put together a nice, freely redistributable interface to a good, solid backend RDBMS such as PostgreSQL and the effort you'll likely save will be worth more than the sub-$1000 price tags
WebObjects will let you generate most of the view, edit, insert, delete functionality you need with minimal effort. It can be used to generate a standalone java application or a web-based interface. It'll talk to anything with JDBC - including PostgreSQL.
There are a few open-source workalikes of WebObjects too, that you may want to look at.
Another option is Qt. It has a fairly easy RAD environment for developing cross-platform apps in C++, and pretty solid SQL support, including database connected widgets for fairly easy quick-and-dirty view, insert, edit, delete functionality. Free for GPL code on Mac, Linux etc. Commercial, but reasonably priced, for Windows.
Report generation sucks. If you don't want to write your own, and can't live with the generally poor level of open source reporting engines, look at Crystal Reports - which sucks too, but sorta works. I've looked at most of the open source / free reporting engines. They may be usable if your standards are very low, but they're pretty nasty.
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.
Interesting point, AC, although every end-user sample that I looked at on their site seems to be browser-based. (Well, IE is shown with a toolbar plugin, but that doesn't seem like it would be too hard to replicate in pure HTML.)
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
I think this parent post makes a valid point. There are so many posts thrown around in many story comments that suggest reinventing the wheel just so that apps are written in the latest scripting language and using the latest IDE toolset. Sure you can improve things or migrate things. But totally scrap something and start all over again from scratch? That's a pretty desparate measure. If I was the boss I certainly would want a detailed explanation supporting why someone would need to tank so much of their time.
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.
Learning PHP and SQL are easy if you have a decent understanding of logic. That's why so many people use the combo. There are also a host of scripts already available for you to copy and paste, and no license worries if it's for internal use. Need a solid framework for your app? Why not write it as a module for some open CMS like the Nuke family or dotProject. Oh, and my personal experience shows that finding a replacement PHP programmer is a lot easier than finding a replacement FileMaker programmer.
Any moron can just say "make your own" without knowing what that really involves.
Most of the morons here actually DO know what's involved, and I'm guessing that's why he 'asked slashdot'.
Literalism isn't a form of humor, it's you being irritating.
Part of the problem, that I (and many techs) have is that we want it all. In the case of any technical infrastructure discussion, it is rarely possible to "have it all." (aka: Fast! Good! Cheap! You can have two of 'em, but not all three.)
In this case, having it all entails migrating to a solution that replicates/improves upon the existing solution without having to do a lot of programming.
Forget it. It'll never happen. If you migrate out of FM, you WILL have a ton of coding to do to replicate the existing functionality, and you'll be employing a hodgepodge of technologies that may work, but will take time to develop, learn, troubleshoot, and maintain. (Take your 6 mos and double it...) Plus you might not be able to come close to the things fm does really well: interface and printing.
Although FM7 is different, many solutions can be imported with minimal changes. It might make some sense to recode your system from the ground up, but you might be able to import with some minor mods. (If you have a number of FM Pro licenses, use that to your advantage-- get your FM sales rep involved and get them do some work for you.)
There are advantages and disadvantages to both sticking with FileMaker or migrating to SQL. (Migrating out MIGHT be the best choice for you...) However, certainly look before you leap, and compare the advantages/disadvantages of both systems before deciding.
Just shop around for one that is well-designed and uses technologies you're ready to support in-house. PHP or Java or .NET or whatever hitting MySQL or Oracle or SQL Server on Windows or Unix. Ask the company how the application is designed. Is it uncoupled from the database? Does it require queuing? Is it a SOA design that can be extended easily? Does it have desktop and web clients? Is it based on one of the open source or commercial portals, like Plone or Content Management Server?
I'd say it's a good bet that you'll find something out there that fits the bill. If anything at least you'll be able to justify writing one because you did your homework.
This could be a good place to start.
Let the students code a system for tracking grades?!
I hope they have a robust honor system at the school.
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
omnis has been out longer than filemaker. i've been using it to develop multiuser multiplatform applications since the 1980s.
it can be a front end to just about any SQL database product, and has its own proprietary file management system as well.
the report writer and screen generation facilties are excellent, and it also allows web interface development, and the basic development system is only $249
www.omnis.net
Ask Me About... The 80's!
For the sick puppies who actually like PHP, there's the PHP-GTK coded Agata Reports which is a general reporting front-end.
Free Gamer - Free games list and commentary
To all you out there saying a php/mysql solution would take months to roll out obviously haven't started using the pear libraries to your advantage. I develop custom CMSes all day long for different clients each wanting to do many different things, and can finish a complex one in a matter of 4 - 6 weeks. Its simple, Html_Quickform can easily in a OOP way handle your form creation and validation. Within an hour of reading the simple documentation i was coding my own. Template_IT also handles templating, so i can make standard templates for commonly used things. If i'm going to use a chunk of html more than 2 times i'll make it into a template. This speeds updates and changes, make it once, changes on all 100+ pages. Same goes for your front end and report, there are pear libraries for pdf generation which can easily handle report generation, you can also use php to generate csv's ppl should already know how to use excel, they can format the data themselves. On my cms i will provide only a couple simple ways to display and output data, but then give them access to the data in a raw format so if they need to analyze it or rearrange it for display to someone else they easily can.
A full cms w/ the proper tools and understanding of OOP programing (how to use an object and how to use a class) can make this easier, of course a lot of this would take into account you know how to run standard db queries.
Filemaker 7 CAN smoothly migrate from 6.
You do NOT have to start over again from scratch.
As with most filemaker upgrades, the changes mostly effect the creation of new things and not the previous version's databases. So to take advantage of all the new features, you sometimes have to remake stuff; otherwise, you can just keep things the way they were.
Filemaker hardly ever forces you to update your databases for them to function. (other than a simple file convertion)
I thought Filemaker 7 was proof they are moving in the right direction.
I have experience in what school systems do, and I do not see a benefit for you to switch out from filemaker. Unless someone makes you a full blown system to do everything you need and open sources that, building it yourself is going to cost you much more time and trouble.
Perhaps you should gather the FUNDS and work with other schools to develop and open source a replacement for your custom solution. Only then, will the open source benefit you, because the work will be distributed between multiple school systems and lower the high cost of an open source alternative. (don't get me wrong, open source stuff is cool, but what you need is quite vertical.)
Democracy Now! - uncensored, anti-establishment news
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.
If I had any mod points left, I'd mod the parent post as a troll.
I use PHP/MySQL. I also use M$ Access. I've also used FoxPro, FileMaker and SQL Server.
Comparing FileMaker to PHP/MySQL is like comparing apples to spinach. Being part of the same generalized group does not mean they are interchangeable.
The user/developer base, and technical skill levels of the two groups are quite different.
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.
nearly - perl + postgresql (real programming language + DB instead of toys)
Eventually, I beleive there will be standard support for real browser-based GUI components. Until then, we are forced to deal with the GUI wannabe crap you get from web-based apps.
Its called webforms. BTW if your making an activex control your using a fat clients GUI api and know how to make a win32 app.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
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.
"How many people really give a shit about multiple OSes? Really."
Did you notice in the story that the school is mac-based? Have you ever tried to access mac data files from a PC?
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...)
I personally think that anytime a large ammount of data is involved (like when using a database) it is reasonable to want some sort of client/server setup so that all the data isn't transferred to the client, but rather only the information they want. A web interface does this nicely. It also allows you to access it from anywhere. Using web based forms is nice but it's not always practical.
At work we've been experimenting with Oracle Application Server and I think it really is the Holy Grail. If only someone else would put together a nice open source version of AS for something like PostgreSQL or mySQL I would jump on it.
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?
To easily generate web forms from any database, we are using PHP with the help of some powerful framework like Smarty and the ones coming from PEAR.
.
:m l
In particular, have a look to QuickForm or to DB_DataObject_FormBuilder
You can find nice tutorials on these technologies
http://www.thelinuxconsultancy.co.uk/quickform.ht
http://www.sklar.com/talks/quickform-oscon2004
http://www.21st.de/downloads/rapidprototyping.pdf
With these frameworks, you begin to reach the productivity of RAD tools "à la" MS-Access PowerBuilder, FrameBuilder, and co . But still keeping the advantages of a web deploiement and the avantage of OSS.
Hope this helps.
Sounds like something you might want to do with OpenOffice.org. It's quite capable of using data directly from a PostgreSQL (or other) database, and performing mail merges with it, which should enable you to create pretty much any sort of form you need.
\\'
WebObjects, while not free, will get you a really easy way to build a GUI for accessing your data in a relational database.
Demo developer version available from connect.apple.com with a free ADC account.
Direct2Web is one of the easiest ways to do your RAD and get clients or yourself up and running.
That's exactly what I did, since I already have a slew of web apps set up for handling other administrative tasks for my boss & coworkers. I just added a menu option and and wrote an include which handled the relatively simple inventory tracking/reporting tasks which the filemaker solution handled. It generates reports in an excel file as per accounting's specs with a simple click. I also addressed their longstanding complaints with the Filemaker interface, and they love how much easier the new interface is to use. Also, now when their leased machines turn over, there's no need to reinstall filemaker again and again. IMHO, web apps rule.
Given that, if one is not already running web apps, there is more of a learning curve. But I started out using access & filemaker, and I find apache/php/mysql to be much simpler and more powerful than either of those two, especially if you are doing more sophisticated stuff.
As an aside, IANAMU (yet), but I have heard that OSX has some type of integrated support for apache, so I think that one in the mac camp would do well to look into that. I am personally very curious to see the OSX take on Apache.
I agree with your observation. That's why we have been working on a free (GPL) project for the past 5 years to fill this gap.
Our project is called OIO and implemented using Zope/Python. You can either use PostgreSQL or Oracle as the DBMS backend. By creating web-forms through browser-based wizards, the OIO system builds the database tables for you. There are also data mining and report-generation modules. Screenshots [ OIO Reporting module | screenshots OIO forms editor ]
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!
Good point, and good links too. However I'd imagine that the question-man would have rec'd much more valuable advice if he'd have given us more detail about the project. How many databases? How complex? What's the main function of this app? How many end-users? Und so wieter...
Best quote on asking for programming advice comes from John Lennon: "The love you take is equal to the love you make"
Literalism isn't a form of humor, it's you being irritating.
With regards to your specific situ, it's probably the 70% slowing you down to a crawl, and it's probably due to lots poorly designed queries.
Not defending ODBC, but merely recognizing that report retreival/querying is a different beast than transactional querying. Your fundamental goals are different and should be focused on reducing query times and minimizing large data retreivals. Let the server do the work and just respond with the needed data.
But hey, you probably already knew that and designed your ASP/JSP hybrid interface to deal with that already, right? ;)
You better watch out, there may be dogs about . .
Not sure if this will help....
But it's a reporting tool that allows you to use Access reports to publish them to the web in Adobe PDF format.
http://www.access2pdf.com
You could use PostgreSQL or MySQL as the database server and then do the typical LAMP Linux/Apache/MySQL or Postgres/Perl or PHP solution.
Or replace Linux with Mac OS/X if you want. The forms could be make into webpages and you would half half of your solution. Where you will have issues is with printing reports. You could use Perl to generate the reports but at least under Linux you will have issues with printing out fancy reports. You could also write the program in Java. MacOS/X is a great platform for Java.
One weakness I feel that Linux has is printing. Althought I have to admit I have not played around with CUPs
Good luck
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Well, I think if one has to keep reinstalling / upgrading applications on lots of ppl's leased computers throughout an dept. as the leases roll over, then web apps become quite attractive.
Those gee-whiz features you cited sound like something you read off a glossy brochure from the PHB's desk.
Why is that everyone in the FOSS community always wants EVERYTHING to be a web-based application.
I dunno. Isn't that why Java exists? Write simple db transaction code into a standalone java app using Swing for the UI (develop it with something like NetBeans, XCode) and let each platform's JVM do the rest.
Those who laugh at you for you having a Mac.. are the people who constantly call you to fix their PC.
Just curious: which features of Oracle AS you cannot find the equivalents in the FOSS world?
I have been using Oracle products for long time but abandoned OracleAS because of the multiple free equivalents available and poor quality.
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...
"First off, Postgersql requires that it be run as root"
Strange, on my systems it runs as the unprivlaged user postgres and NOT root. Wonder what you did different.
Ha, I never said I designed it. I do know the programmers used Microsoft's ASP GUI tool to create the pages in the original software, then IBM WebSphere to create the new software. While the old software seemed primitive, it is faster and more stable than the new software.
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.
= 9J =
US Democracy:The best person for the job (among These pre-selected choices...)
So you'll never have a great port, particularly if you try and leverage the same database backend.
I could be WAY OFF on what Websphere even is, as I've never used it and have only had it on my resume as an expert for a few months.
You better watch out, there may be dogs about . .
There is PHPMyEdit and its derivatives. It is nowhere near as comfortable as some of the Windows GUI apps, but it covers some of the same ground: it makes it easy to put together simple database apps quickly.
A client app? You mean like a web browser? :)
This is my sig. There are many like it but this one is mine.
Hmmm... this client-server architecture you are talking about? This wouldn't happen to be similar to a client accessing a web server would it? Oh it would? Hmmmm... fascinating. And this flaming you are attempting would be pointless? Ah, I see.
As for this being 2004, holmes, I congratulate you on your superior date reading skills. Had you not informed me of this fact, I would have assumed I was still in the year 3065. You humans are useful as well as amusing.
So you say quick easy changes occur more easily than using a web tool? And the crack you are smoking is how much?
This is my sig. There are many like it but this one is mine.
We went with Swing for our last project since it was supported on all the platforms we needed to target (OSX, Linux, and Windows), thinking to ourselves how clever we were for "leveraging" such a powerful tool. That was until our client started pointing out dozens of tiny visual glitches (line wrapping cutting off characters, Layouts that didn't perform identically on all platforms, etc.). It gets worse when using the platform native LnF wrappers.
Not to mention internationalization errors, the cause of which we STILL can't track down.
As a direct result of the pain of Swing, we're buying a multi-platform Qt license.
iList Studio is a graphical front end to MySQL. It supports forms, reports, all in a Macintosh application (no, I have no relation with them). Reading between the lines of the web site, it looks like they were doing their own DB and then switched to using MySQL as the back end. Because of that, they've added some "meta types" to MySQL, including calculation fields and images. It isn't free, but it is less expensive than the FileMaker 7 upgrade.
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
... or instead, you could get it from totalrekall.co.uk. The developers Open Sourced the product. The Kompany no longer control it.
"The dew has clearly fallen with a particularly sickening thud this morning"
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.
:)
:)
Ok, and how does this differ from web development? With Apache, XML, SSL, etc, web browsers do the same thing
Your problems sound more like a problem with the way the tool was built and the database was optimized. Can't really blame that on web development. And as I was saying, this is NOT THE WAY TO GO, if you plan on building desktop apps, but if you want something to be accessed by people all over the place and be database driven, you still have yet to convince me.
As for using ASP, that explains your problem right there. That stuff is a nightmare of crap. Should have used PHP
This is my sig. There are many like it but this one is mine.
Last time I checked, XDoclet generated _some_ forms... with validation, etc. Never actually used'em though.
"If anything can go wrong, it will." - Murphy
Check out AthenaRMS. It is a request management system but has very flexible form creation abilities and custom reporting. It can hook in to MySQL, PostGRES, and Oracle. AthenaRMS 5.0 is Open Source and listed on SourceForge. 5.1 is done and the forms customization is much better but that hasn't been Open Sourced yet because we're still researching licensing. For more information check out the AthenaRMS website.
Heres the idea:
- Have your students do it
- Have someones else's students do it
- Have a subcontractor do it. Note: See pts 1 and 2
Its a private school. Have the students/parents/endowment pay for the privilege. Its good for the economy.http://www.pdcware.com It does 95% of what most people need to do without the bullshit of access etc
I have done this using LaTeX. I write the app as an Apache CGI in Perl. I use an HTML form to set up the query specs, send that to the Postgresql (MySQL is another good solution) via Perl's DBI module, and read back the results row by row. I send the output to a temp file on the server (careful, security issues here), formatting cells with LaTeX commands. The tex file gets pushed through pdflatex to produce a pdf file, which is sent back to the browser. PDF files print real nice, and not just on Windows.
The only problem I've had so far is knowing exactly what row I'm on, to get page breaks in the right place.
Now, for the form layout tool. A GUI is nice, so I use Lyx. Lay out the report headers and page headers however you want them. Most report data will go in a table -- make up a few rows of dummy data. When it prints the way you want it, export as a LaTeX file, and use that as the basis for the Perl code. I tried to include sample code but the /. lameness filter got in the way.
Gary Dunn
Open Slate Project
what we're doing right now where I work. Our solution: Apache 2 + mod_python + mysql. It's been working pretty slick for two years so far. Pretty much everything is migrated from the Filemaker databases now--everything runs through the webserver.
'Phone-jacking: Give someone a ring, they'll have to answer to find out who it is!' - Threni
In the past year or so, I've built both a Filemaker database and PHP/MySQL-based solution while working for a small non-profit educational organization. While my own preference is the web-based (PHP,MySQL,XHTML,CSS) solution, I'd highly recommend going with Filemaker as most organizations of this nature can't afford to train/employ PHP-savvy developers. Filemaker isn't the greatest as a database solution, I actually prefer the usability I can create with a web interface to it. But Filemaker is easy to learn & develop in - it's certainly a confidence builder, and this may be its most important feature for small organizations with limited budgets when it comes to employing dedicated techies.
I used Filemaker two years ago in a decent-sized k-12 school setting and we did nothing over the web -- it was all through the built-in Filemaker client. Not that my experience means much about the world in general, though.
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.
... interface that everyone can reach and access make it easier to maintain.
Flawed assumption. The database still lives on one machine. With a GUI based application, it is actually possible to ship less data per screen to the client than with an HTML based app. With HTML you have to ship markup plus text. With GUI, you only ship the text (having shipped the markup as part of the initial install, instead of with every page load).
Second, one
Agreed, but only from the software distribution standpoint. Writing for web or GUI is pretty much the same in terms of difficulty.
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.
Your web screens are your user interface. They have to learn the flow and layout just like they would in a GUI app. GUI apps, however, are a bit more mature and have more standards (File, Edit, and Help menus, Copy and Paste icons, etc.)
It's portable as well as long as you have a connection.
Definitely true, and one of the best reasons to use web applications.
For database driven apps, it's pretty much the best way to go.
Speaking as a hammer manufacturer, I must tell you that this problem is clearly a nail.
Stop-Prism.org: Opt Out of Surveillance
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.
How many people really give a shit about multiple OSes? Really.
;-)
I don't... but there are a lot of people out there running Windows that might want to run something that wouldn't run on their platform if it wasn't a web app.
--Phillip
Can you say BIRTH TAX
all the time actually. it's not 1987 any more dude. macs and PCs are very interoperable.
ASP -- the technology -- is different from ASP the business model. An ASP -- Application Service Provider -- enables businesses to have web and client server applications without having to host their own servers or build their own pages. Furthermore, ASP -- the technology -- is no better or worse than PHP -- they're just alternate forms of scripting to build dynamic HTML, and ASP is much better at interacting with COM (very important when you have modern VB/MFC apps you want to put a web front on). Conversely, PHP is better when used with Apache.
Web development (which looks like what you quoted because that's what I was talking about, duh) uses many of the same technologies as client server programming. The difference is that the server controls EVERYTHING. A smart client has a certain amount of autonomy, which is useful. If a web server crashes, chances are you'll lose your web session and the work you were doing. If an application server crashes, you can usually queue your changes locally and resubmit them when it comes back up.
if you want something to be accessed by people all over the place and be database driven, you still have yet to convince me
Try comparing an online HTML based game with an online Java client game. The client will not only be faster and more enjoyable to play, the server running it will be more robust. Internet applications are the same way...for small things, like posting this, the Internet is painless. For writing anything bigger, I want a damn client. I have a 1.25 GHz Altivec processor, goddamnit, I don't want to have to wait 30 seconds for a web response to tell me i formatted my SSN improperly.
Hey freaks: now you're ju
Hmmm we were talking about databases. I was referring to Yahoo using a "toy" (MySQL) as a humorous way of making a point that MySQL is used in rather large-scale operations. Doggone it, I was on topic, and I was robbed the karma of my 'funny' rating.
In the name of justice, metamoderate!
My biggest complaint with web apps is that sometimes, the user model is just wrong and is way too limited. There are many UI things I just can't enforce with a web app. And, sometimes I want to limit who can access what - it's a lot harder to access something with a custom client than with a web interface.
Maybe if somebody figures out how to make a web site behave more like a regular app, fine. Until then I'll use whatever tool fits the need the best. If I need a large number of clients I'll have limited functionality with a web app. If I need more control, I'll use a FIlemaker solution.
I just finished putting together a system for a client in Filemaker. While a web gui would have been easier in certain cases, I didn't feel that the gui was as flexable. With Filemaker I can scale the solution from a single machine to a client/server system. I'm not saying it's perfect, but it was the best choice.
Now, if Filemaker could come out with a product that keeps the gui, but uses an external db, they may have something.
I use Macs to up my productivity, so up yours Microsoft!
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.
I'm at the annual FM developer's conference right now, and they just released FM Server advanced, which is ANSI SQL compliant with ODBC/JDBC, directly ports XML in and out and parses XML using the XALAN engine, and does lots of other groovy stuff. A single field can hold 2 GB of text, the container field type holds any binary data now, and the new relational model allows you to hold "joins" as stateful objects which display live data via the relationship.
There are a beautiful set of classes in PHP to build web pages via XML interchange at iviking.org. These are open source.
OTOH, I have also spent some time with the servoy guys www.servoy.com which is an amazingly worthy SQL front end gui building tool; I am absolutely blown away by this product. So take your pick, FM is great, servoy is great, PHP as a web app front end to PostgreSQL would be great, it depends on time, budget, concurrent users, dataset sizes, etc.
Actually, in web development, there is client side coding and server side coding. That which doesn't have to be run on the server, shouldn't. But because most web server people are constantly worried about security, they like to maintain control.
:)
As for a crashing server having you lose where you were, well a crashed client system wil do the same thing... duh. Imagine that, a client crashing? That NEVER happens does it? Quite honestly, I have clients crash FAR MORE than servers... especially when you aren't there maintaining them like your server.
Oh and sorry to tell you but in a side by side comparison by a third party (Oracle), PHP is faster... even when it is on a Windows machine. Do your research.
This is my sig. There are many like it but this one is mine.
Well you should always use the tool that fits the need best.
And all web apps can scale, have limited permissions and you can build the GUI to look however you want it to look.
This is my sig. There are many like it but this one is mine.
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.
Split the app into a client app which handles presentation of the gui elements/db connectivity, and a set of UI layouts/app functionality. Go nuts and create a MacOS app, a Windows app, KDE/Gnome/GTK/Qt/Curses/whatever versions. The app itself handles platform issues, the UI layout handles common functionality.
Basically, a cross between Filemaker and the web/html.
I use Macs to up my productivity, so up yours Microsoft!
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*.
Well you should always use the tool that fits the need best.
Agreed, went into that in another comment.
And all web apps can scale, have limited permissions and you can build the GUI to look however you want it to look.
What I was trying to emphasize is that the most I can really do is enforce security through userid/password and the url (and I have built apps which use different url's for different functionality). With a custom client, if you don't have the client, you're not getting in at all (unless you can fake it and know the specifics)
I use Macs to up my productivity, so up yours Microsoft!
You evidently haven't written programs used in a big Windows LAN, where it's quite popular to lock down the client machine. The end user can't install new software. It all has to go through the IT department. In schools, IT is usually in a district office somewhere, and they visit the individual school only when absolutely necessary.
Yes, "ghost" tools are popular in such LANs, but you'd be surprised how much convincing it takes to get some IT departments to update the client image. We've had rollouts of necessary fixes delayed 6 months just because the IT department wasn't ready to change its common client image.
We've also got a Web-based version of the same app. We want it updated, we dial (or ssh) into the server, drop a tarball on it, and it's done.
by working 69 times as hard!
Say it right: "Nuc-le-ah Powah".
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"
This is an anti-OSS troll, and crap. The GPL will not retroactively convert your in-house code to OSS, period! This is patently FUD and a lie. If this is really a consultant for the fortune-500, the client deserves what they get.
As a previous poster pointed out, Postgresql does not require running as root, and doing that goes against ALL the docs.
And who the heck is running a "Linux mainframe"? That's consultant-speak for "the most expensive computer the client bought while I was working for them." My experience with big-ticket consultants is they identify the most dim-witted sycophant on the staff as their guru, and then, when anything goes wrong, they ask the dimwit, "what gives?" As for rebooting after altering a table, well I think the dimwit got it wrong.
In this case (if, on the remote chance this isn't a complete troll), the $100K consultant advised the company to spend another $100K on SQL Server licenses, the dimwit gets a promotion, the consultant rides out on his donkey, and everyone lives happily ever after. And they all deserve each other.
OK, I know... IHBT IHL HAND... Grrrr!
Everything I've ever learned the hard way was based on a statistically invalid sample.
First off I'd like to offer some of my background in using databases to help illistrate my point. I used FileMaker for a number of years, but as our databases required more and more perfromance we had to move on. First off we used 4D which has many of ease of development pros of FileMaker, but still isn't as high perfromance as offerings like MySQL... which is what we use now.
I love the power and simplicity of MySQL in many areas, but when it comes to wiping out a user friendly entry form (esp when related tables, data entry checking, and etc) FileMaker is a far quicker enviroment to work with.
Yes you can do everything for an entry/edit form in PHP or Lasso, you can't make the entry forms nearly as quickly if there is any level of customization involved.
I think this illistrates a whole in open source offerings... it would be great if there was a easy to use, and quick to emplement database front end for the likes of MySQL
I'm in a similar situation, but am forced to start from scratch (I got hired by a new company that has nothing pre-exising, so I can choose my front- and back-end weapons but cannot bring along my FM6 databases from my old company). My twist is that I require support for formatted text (sub/superscript, italics, preferably ability to mix in Symbol-font chars). Any solutions other than FileMaker?
Try pronouncing "labtop" with a northern European accent (Teutonic, not Slavic) and you might just understand the confusion some people experience.
But in the case of native English speakers, it's just weird.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
I wonder how long before it supports other database engines (MySQL, etc)? Then you'd probably be able to layout your forms in Interface Builder and bind the controls to the database... We can wish for it, anyway :-)
he's faced with spending a lot of his time any way he goes, stay, upgrade or convert. He said that moving to 7 would require him to rebuild all of his databases. So he and others will spend plenty of time on the upgrade train and it might add up to more than one man year of effort.
The reason he's bothering is the binary blues. Sooner or later, the equipment that runs his current version will die as will his binary install media and then the conversion will be harder.
There are obvious benefits to using a free database, so he's looking for advice.
This is not a complicated decision. Millions of businesses make similar decisions every day.
That's what makes investment so difficult. What you said sounds reasonable but it's dead wrong. I've had PHBs like that, yuck, who don't know shit and then make you explain why they did things to begin with. Companies with too many people like that are a bad bet.
Friends don't help friends install M$ junk.
If FileMaker 6 works for you then don't upgrade, at least not yet. Sure, 7 is much better, but for existing systems it doesn't really offer any benefits unless you feel something is missing. (If it ain't broke, don't fix it)
I am feeling fat and sassy
My company was in the same boat, but coming from Access. Oracle can be really affordable, and if you are coming from Filemaker, you are already used to paying license costs. UIX in JDeveloper makes drag and drop, full featured database forms & applications pretty easy once the initial curve is done. We've found it as fast as Access to develop in. You can deploy to Tomcat on whatever machine you want, and pay only for a JDeveloper license. You could even use Mysql (supported) or Postgresql (a few gotchas) as your backend, this is what we did for a few test applications. We moved to Oracle Standard Edition One, which is 5k per processor, for up to 2 processors. Since the java web frontend caches all the tables and queries, you hardly hit the database backend at all, so it can support a LOT more users.
I think you're trolling about the whole UNIX GUIs are hard bit. The rest of your post makes good points though.
First off, when an individual FOSS developer sits down to write a GUI app, he doesn't fight about KDE/GNOME, packaging, or anything else. He decides which he will use based on his own preferences and requirements. If he uses GNOME or is writing the app for someone that uses GNOME, he will use that; ditto for KDE. Packaging is probably dictated by the OS he develops on initially; he can assume (rightfully) that people who want to run his developed-on-Debian app on their Redhat or SUSE systems will contribute makefiles and build scripts to make rpms while he maintains his debian/ directory. Sure, it seems complex, but in FOSS, this is how it works, and this is why you end up with an app that runs on every POSIX platform under the sun, translated into every language immaginable, etc.
Now, in a company setting, he doesn't make those decisions, his managers do, and those decisions are generally arbitrarily based on stuff managers care about. The packaging will be tied to the system in question. Again, no arguing. I realize Windows people are frustrated by the amount of choice on UNIX systems, but managers are used to making choices: they point and say "that one". They might have a meeting about it, but in the end, it doesn't matter.
The truth is, developing GUI apps on anything but (maybe) a Mac is generally a pain in the ass. GUIs are hard to do, in general. If you get right down to it, no one likes GUIs.
If you work in IT, you'll probably realize that lots of managers want web-based solutions. There are lots of reasons. First off, there's the RAD angle -- GUIs are a pain to develop well, and usually we don't need overly complex GUIs for DB entry anyway. Whereas developing a good GUI can take months to years, a good web-based app can take half as long or less to develop/debug/launch.
Furthermore, there's the write-once-run-anywhere angle. While this was pretty much a pipe dream for Java, web-based apps that do all their computation server-side make this a reality. So anyone with a browser (that is, anyone with a computer, ie, everyone in your company, probably) has instant access to the relevant web apps. No installation, no calling IT down for the admin privs required to do the install, etc, etc. And with web-based apps, the designers using Macs, the office drones using Windows and the server guys using UNIX workstations all have access if they need it.
The web spells accessibility.
I've been doing DB-related dev since the dBase days, and it's been a while since my employer has wanted an in-house solution that isn't intranet based.
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
The closest fit filemaker has in the main stream is access. Both are slow, and poor excuses for databases. Problem is neither are marketed as databases. Well somepeople would argue that filemaker does, but having had lunch with one of the lead developers on the new filemaker version this summer I would say you will see a shift even farther away from being a 'database' and more for a data tool.
The guy put it like this: With MySQL I can input millions of rows, querry them and puke them out about 7-10 times faster than I can with FileMaker. However that is because it is just raw data and I am smatter than 99.9% of the people dealing with data. Want to get particular reports and other things from them and FileMaker trounces any Database People want the ease of use and reporting tools, and most people already using our product love that. Why train soccer moms to know SQL, PL/SQL and JAVA just so you can have a real Database.
However if the argument is free as in freedom or free as in beer you have Filemaker on that front, as well as Oracle, SQLServer and most of the popular DBs (I know MySQL and others out there are free but lets look at the headaches and hastle of that switch over)
Sorry, your best option is either stay with what you have or try and get the school to pay for the upgrade....
Just as a footnote, while it is technically possible to run an LDAP off of Filemaker (so sayeth Filemaker Developers) WTF, please tell me that I am just misunderstanding that.
Well I see what you mean. You want to have user groups with functions assigned to each and then assign people to the user groups, right? Yeah, this is something each programmer has to figure out.
I myself am working on precisely this using PHP and MySQL in a custom content management system for companies so they a company and it's many brtanches and many depts can manage it's website with each dept handling their own part of the site and each branch manager handling their branch, etc etc.
It's not easy but there are easier solutions. Just simplify the hell out of the process and determine the MUST HAVE needs.
This is my sig. There are many like it but this one is mine.
Unfortunately it isn't applicable to your case, since this is a KDE application, but I believe Knoda, which works with MySQL, PostgreSQL, SQLite, and ODBC, and is scriptable with Python, sounds like it does much of what you need:
:-)
http://www.knoda.org/
It's a lot of work just to replace FileMaker (probably more work than upgrading, although you would get the desired SQL backend), but one possible option is to run X and KDE under OS X. I don't have a Mac and am not familiar with how well this would work (or not), so maybe you're sitting there right now and wondering what I'm on to suggest such a thing
Since you're in education -- you may take a look at .LRN over at OpenACS site. It is what MIT is using for open courseware, and so does Carnegie-Melon.
It is based Oracle or PostgreSQL backend, with AOLServer serving the content. AOLServer has a built-in Tcl interpreter that is used to build the whole solution (there is nice separatoin of logic and presentation built as ACS Templates package that makes build ing forms *really* easy).
--AP
I'm just surprised nobody suggested the DB stuff for OpenOffice.org .. *shrug* ..not sure about data entry, but should work for report processing.. that and any number of web based tools, php, jsp, asp.net (mono for non-windows)..
Michael J. Ryan - tracker1.info
If I were in your situation, I would come up with a solution by scratch. My solution would look like:
Web-based interface built upon ASP or PHP, using an SQL backend of some kind. Interface allows viewing, modifying, and saving records. Use HTTPS and MD5 hashed passwords for security, or something.
Ability to download files for offline viewing/editing - files would likely be in XML format or similar.
Small home-built GUI app for viewing/editing offline files. Allows ability to interface with web-database and upload/download updates to files.
Easter Egg. Include a small "Punch that annoying office paperclip" game when the user presses CTRL+ALT+SHIFT+1337
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
I'd just like say Thank You. It's about time that someone posted a decent question to askSlashdot. I don't just mean that it's a good technical question, but the fact that the author actually bothered to spend the time explain the question and to give the detail and background to the problem.
2 5234&tid=126&tid=215&tid=137&tid=4&tid=218
3 57212&tid=222&tid=4&tid=218
Most of the recent askSlashdots have just asked one line question that are left so open to interpretation that the answers people provide couldn't be any more unrelated! Many of the replies end up just asking for more detail about the question because the best solution to a problem relies on knowing some of the background information.
The other types of questions are either too specific, like the What is this Strange Gadget in My Car? article, that I really don't think this is the place for
http://ask.slashdot.org/article.pl?sid=04/08/25/0
or the answer seems so obvious that it's a waste of time, like How Do I Disable My Gadgets' LEDs?!
http://ask.slashdot.org/article.pl?sid=04/08/30/2
I hope to see more postings like this one in the future.
That's a bit harsh. It's like saying Windows developers fight about Delphi vs Visual Basic vs Access vs Visual C++ and then have to choose BDE, ADO, DAO, DBExpress etc.
Actuallly - no. People use whatever they evaluate to be the best (or are most experienced with etc).
If you want to write a GUI app go right ahead. If I was doing a GUI database app I'd probably use GTK or Qt because they're so much easier than dealing with the general badness of Microsofts GUI APIs (I don't have any faith that the Delphi VCL will be around for the long run ...)
For this particular situation, it is probably the simplest approach. PHP works nicely with mySQL, you don't have to put too much work in the interface, there's tons of stylesheets out there that you can maybe edit a bit and then integrate with your app so everything looks nice. I think when it comes to rapid application development in FOSS, people will most generally use something web-based.
Off course there are other concerns such as compatibility, which is another advantage of FOSS. If you have macs and windows computers to deal with, they both have a working web browser (firefox) which you can develop for. Writing a C app that does the same will require some porting, which will be more work. (but this was already mentioned above).
I'll tell you "what the fuck" version of the PostgreSQL docs I am looking at. It is 7.4. I'll even tell you "how the fuck" can you go there. Go to PostgreSQL official website at www.postgresql.org. Click Docs at the top of the page in the main menu. Select Static Documentation for the current version of PostgreSQL 7.4, right at the top of the page, the very first thing below bold and underlined "Official Documentation." In the Table of Contents skip Preface and go to the Part I of the documentation entitled Tutorial. Find the word "joins" in the Table of Contents for this part. There is only one instance, namely 2.6. Joins Between Tables. Voilà! Now search for the word "Exercise." There are two of them:
Are you "fucking" satisfied? Call me oldfashioned but in the official "tutorial" for the leading RDBMS I would expect a little bit more on outer joins than leaving them as a pathetic exercise for the reader. Next time before you start using vulgar language please do a little research and please at least try to stay calm. PostgreSQL is unquestionably the best free software RDBMS. It is clearly superior to most of proprietary systems as well. It has already singlehandedly beaten MS SQL Server and beating Oracle is only a matter of time. No question about that. But let us not forget about the documentation. Of course for you and me outer joins is something utterly obvious and intuitive, but remember that there are people who are beginners to computing and programming in general and set theory and relational model in particular. We should forget about our infantile "leetism" and doubtful "intellectual superiority" if we ever want PostgreSQL to be ready for the desktop. And most certainly starting our sentences with "what the fuck?!" does not make us look any more competent in the business and scientific community. Let this be an appeal to everyone who often forgets that cursing like a drunken sailor does not help the free software movement, myself included. Because if we continue looking like a bunch of simpletons in the eyes of businessmen and politicians, our products and our agenda will never dominate the market of profanum vulgus, notwithstanding the meritorious superiority thereof.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
OOo can access MySQL (or just any database) using ODBC or JDBC, creating the reports and mail merges is a breeze. With a bit of custom scripting, you can get even very advanced reports.
What a load of BS ! I hope you're trolling :)
Firts, postgresql does NOT need to be run as root. It will even display an error message if you try to do so !. The default is to run it as postgres.
Although I only use postgresql to host small databases and run simple queries, it works perfectly OK (and I'm a prof, and give my students access to my really crappy server (PII 400, 256 RAM), in which they run their toy databases too).
Now if you've told me it lacks things like distributed databases, ROLAP queries and such, that would be a decent criticism.
the best interface I've seen for PHP is: http://phplens.com/lens/ It's very nice for PHP database development, but it is not FileMaker. Good news is, since it's built w/ ADODB interface it'll hook up to a large number of popular databases, so maybe with a little bit of PHP work you can have your system moved to a more scalable environment. Overall a good question, and a surprisingly poor showing from the FOSS community! :P
Web Apps also suck ergonomicaly. We usualy start out thinking web-app to get it going fast, then I'll write the gui interface later; Later never seems to happen and we stay with the web app interface. Eventuanly we quit kidding ourselves, and just say use a web-app interface.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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.
I have about the same credentials as the parent AC, and I COMPLETELY agree.
I've seen just how happy people were to get their own PCs and declare independence from the priests of the mainframe. I've seen how happy business people were to use Lotus and later Excel to liberate themselves from what we now call the IT department.
Filemaker is in the same category as Excel or the PC itself. Its basic functionality is very empowering to ordinary business people and even consumers. People who aren't programmers or sysadmin types can whip up their own personal or departmental databases and do all sorts of useful things with surprising ease.
The fact that these PC or Excel or Filemaker projects occasionally evolve into something larger and need to be "repotted" is NO EXCUSE for disempowering the front line users.
We NEED a FOSS Filemaker equivalent in our FOSS Office suites.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I don't want to have to wait 30 seconds for a web response to tell me i formatted my SSN improperly.
Learn JavaScript, use it to pre-validate your user responses; then use the server side to re-validate the responses. If your not doing that with any client/server system you'll regret it sooner or later and remember using a web browser doesn't exclude using java.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Maybe they heard you callling, because the latest MySQL newsletter has just what you're looking for.
Wow.... An AC dripping with sarcasm
HTML::Mason is definitely as fast or faster than PHP under any circumstances. Test it.
Why did Yahoo pick PHP over HTML::Mason? Because you can find a MySQL+PHP developer hanging out at every cybercafe or war-chalked street corner. Their commonality is appealing to big companies. This is exactly why MCSE and Java developers are more likely to get a development project than anyone else. Because they are easier to replace, not necessarily better.
Oh, I never claimed to be an expert. But I've used both.
"mySQLcc ("control center") is no longer under development,"
.
In addition to MySQLGUI not being further developed.
I have used MySQL Administrator on my Mandrake boxes at home and on my W2KP box at work. I prefer the GUI/CS apps over the web-based controls.
Also I use or "play with" DBDesigner from www.fabforce.net as well as AquaData Studio from www.aquafold.com
For my development stuff for my hobby and for things which I hope to convert and sell in the near future, I use (have been since 1994 or so) Lotus Approach. THAT is a GUI to be rekoned with, for cubicle users.
Sadly, though I can export my fields (less picture and date/time fields (the D&T have to be converted to "text" first), I cannot get correct summary counts on detal tables. Lotus' reply is to bring the data back to the desktop. Since Approach is not a standalone app (as in runtime executable like ms access is/can be), this may not be much of a problem until data synchronization gets out of control when some fields change. They CAN be remapped, but you're likely better off locking the app so regular users cannot change the interface and start adding their own data. If they are privileged, then make them part of the development team's contacts.
What I do like about MySQL is that it will let me use Approach to export my various schemas/tables although my field names have spaces. A former director of mine suggested I "get used to" using underscores in field names and not use spaces. Well, I don't care for databases that cannot cope with HUMAN-FRIENDLY/readable field names. The technology should be smart enough to permit user-friendly field naming, even if the names still have to be truncated to 45 characters or so.
For the longest time, I did not get PostgreSQL to work distro after distro upgrade of Mandrake because I simply did not figure out the password was 'postgres' or 'postgresql'. Now that I've been on MySQL for a couple years or so, and found some nice GUI apps for it, and it has an ODBC (3.51 or 3.52) driver that lets me export and read my Lotus Approach data, I am happy, but not as happy as I'd be if IBM and Lotus dual-sourced or dual-licensed Approach and SmartSuite.
David Syes
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Although some good points have been made here, it seems like most people are missing a key point: by suggesting the use of FX.php, the poster was NOT suggesting the use of PHP/MySQL, rather PHP/FileMaker. So the suggestion would seem to be not be "Just do it in PHP/MySQL", but something more like "rather than arbitrarily discarding your database, why not put a more flexible and powerful front end on it?"
The moral of this story: make sure you know what's at a link, before fuming that someone suggested it =)