The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Web-Based Database Apps
ElJeffe
Registered User, ClubPA regular
Registered User, ClubPA regular
Does anyone know of any web-based database applications that allow you store the information locally? Most of the ones I've seen are apps that require no installation, because the whole thing is run on the company's own servers. I'd like something that's hosted and run locally, while still offering the convenience of being web-based (to the end-users, at least).
I submitted an entry to Lego Ideas, and if 10,000 people support me, it'll be turned into an actual Lego set!If you'd like to see and support my submission, follow this link.
ElJeffe on
0
Posts
Are you looking for something like a spreadsheet that would, hypothetically, allow you to save information on your local machine and then reload it at will? Just so I understand you correctly.
People are currently using Filemaker to run a database filled with information on student employees. Multiple people use this database, so it needs to be accessible from multiple locations. The file itself is hosted on a server somewhere. The problem is that Filemaker does not have a "Save" button. Everything is saved dynamically as you do it. If the network goes down, though, and you don't realize it, all the work you're doing does not get saved. If you then close the app, you lose all the work you just did. This is a Very Bad Thing. The current workaround involves telling the users to open a file on the server as a check to make sure the network is up before closing, but this is a somewhat clunky solution. And Filemaker, in general, isn't that great of a program, and there are a few other problems.
A web-based database app seems like it would solve that problem, since if the network went down it'd be impossible to make any changes at all. Also, I like web-based solutions because they're nifty. However, for security (and policy) reasons, having all this data hosted on an external server would be... troublesome.
And it needs to be more robust than a simple spreadsheet - our people need decent search and organization capabilities, which they currently have. Something like Excel would be inadequate.
:-( unfortunately my experience with Filemaker has left me with a bad taste in my mouth. Their proprietary database leaves something to be desired. Having it work with filemaker would be difficult at best.
You should see about getting the server component as it ties into a PHP website supposedly.
However, you may be able to use GoogleGears to accomplish what you want, if you're up for it.
I think I remember GoogleGears being some sort of DHTML/AJAX toolkit.
It sounds like somthing that could be done with MS Access but i'm not really sure.
[edit] bleh, you said web and i totally glossed over it, i was thinking over a network. but a better description of Filemaker would be helpful [/edit]
The Filemaker database currently exists on an internal server. When you want to alter it, you fire up Filemaker (installed locally) and open it up across the server. The app is running from your machine, though the file is stored elsewhere. Every time you make a change, it gets saved to the server. But if the network goes down, it doesn't tell you. It just keeps right on making changes, but it stops saving them. If the network comes back up before you're done, no worries - it'll just save the file out next time you make a change, and you'll be none the wiser that anything happened. If the network is still down when you close the app, though, it'll just nonchalantly throw away all the changes you made.
I'm trying to find a solution, but I know dick about database software. Unfortunately, "dick" is a lot more than anyone else knows around here.
I honestly wish I could be more helpful, I can't find anything remotely close to what you need that allows for offline->online synchronization.
I hate to say this but FoxPro. The doctor used to use this before I came on board and if the network went down it just stopped altogether (you can run from a network share). When it came back up, it went back to working fine.
Short of something like that, most other databases are strictly database servers. In a realm seperate from FileMaker. Seems FileMaker and FoxPro are their own brand of "Visual Database Systems" where you can build a GUI. I've seen people do it with Access Executables/Runtimes though, so you may have some luck with that.
Sorry Jeffe.
After you get everything installed, the sort of application you're talking about is literally a 30 second job.
You're done.
For certain kinds of applications, FileMaker is just fine. For others, it's not. Its biggest problem is that, due to history, it doesn't look or act a lot like its competitors.
A history lesson:
FileMaker Pro 1 and 2 were database applications that ran on Macintoshes before the dawn of the Internet. Remember, these are small computers. FileMaker was competing against other personal computer databases like dBase, FoxBase (later FoxPro) and later Paradox, which a lot of businesses were using. Personal computer databases in these early days largely coupled the data-entry user interface front-end with the data storage and retrieval back-end. I understand this is anathema now, but back then it was fairly common. FileMaker, having an honest-to-God GUI instead of just a COBOL-clone TUI, was a pretty neat product. It was meant for very limited use initially, though, and so FileMaker 1 & 2 were flat-file (i.e., not relational) databases. No concept of primary key/foreign key, no way to relate tables, etc.
FileMaker around v2 had a really neat feature that few comparable databases had: easy networking. Remember that this is back in the day when local networks were rare, very expensive, and hard to set up. Macs had the AppleTalk protocol which would run over LocalTalk - effectively a string of little serial dongles. Originally these were tied together with serial cable, but eventually an aftermarket technology called PhoneNet could be used that tied Macs together with ordinary phone cord. With V2, one machine could open up a FileMaker file, and the others could use that machine as a server, and you could concurrently edit the same data files.
Then FileMaker v3 came out. V3 had better UI, but it also had something critical that the previous versions didn't: it was a fully relational database. It also added a pretty nifty scripting language and engine. It still had vestiges of the old FileMaker: database design and UI design were basically the same activity. You set up relations not through tables, but through visual metaphors. Nothing else really works quite like it, but it's actually sort of elegant in its own way. It's very hard to imagine for somebody that's never used it, but it's a fully relational database without the SQL. You design your tables and your queries visually, not in code. You can get as fancy as you want with scripts and the like to enhance the UI.
V4 had some plug-in APIs for app developers and there were later versions, but they basically never rearchitected the thing, so it's still this unique player in the database space.
FileMaker 3 (or 4, I forget when it came out) also had two versions: the ordinary client application and FileMaker Server. Any FileMaker client on a LAN could still act as the server for any database. However, when you built real apps with FileMaker (as I did) this setup had performance and reliability problems (as it likely still does) because it's very much a peer-to-peer setup. FileMaker Server is a somewhat expensive but very worthwhile and robust product. It isn't a client, it's just a server program that runs on a machine and does nothing but host databases for other FileMaker clients.
Now this is your major problem right here. This is a Bad Idea. You have the FileMaker database file sitting on a shared drive somewhere, and a client remote-mounts that drive and opens the file, and then starts editing. This is bad, because FileMaker (or any application) operating in this mode is going to get pretty confused when the network goes down, because it's the equivalent of just yanking the hard drive the files is on right out of the machine. Worse, if two clients open the file at the same time (which may or may not be allowed depending on how the latest FileMaker versions deal with OS file locking), you get all sorts of corruption and problems.
You have two options, one better than what you're doing, and one that's a pretty good idea:
Before we continue, terminological police:
You asked in your OP about "web-based database applications." I think I know what you're trying to articulate, but the terminology you're using is confusing. First off, you're using FileMaker as a basis for comparison. As I noted above, FileMaker is very much a database, but it's not really very much like any other database that's still in active use, because of the 1) lack of a SQL-based backend and 2) complete integration of front-end UI and back-end data store. The closest things still around today would be FoxPro (deader than FileMaker) and Microsoft Access. However, Microsoft Access was still designed with the SQL-based backend (originally Jet, now a lite version of SQL server) separate from the front-end form design tool.
So you don't just need a database - you need a back-end database AND a user-interface front-end.
Second, you are looking for a "web-based" application. You seem to mean an application that is hosted on some other company's servers, like GMail or Google Docs. These applications are indeed Web-based. Any application for which the primary interface is a Web browser and the primary protocol used is HTTP is a Web-based application. What you're thinking of are hosted applications, whereby some other organization develops and hosts the application on your behalf. These are also sometimes known as software-as-a-service (SaaS) applications, but this terminology hasn't caught on (and I hope it doesn't because it's awful). A bigger example would be Salesforce.com, which lets companies outsource their customer relationship management to Salesforce, and company personnel access the application through a Web browser.
Many companies, like yours, are wary of putting their data in the hands of some other company. For example, my management would blow an aneurysm if they found out I was using Google Docs to write up my reports and other company documents. This problem hasn't been worked out uniformly across the industry. In the case of Salesforce, companies that decide to use Salesforce draw up elaborate confidentiality agreements and contracts, and they pay for the service. Sometimes, if the application is small enough, the company that develops the hosted application will sell you a machine (or software to put on your own machine) to host a copy of the application on your own intranet. You can buy a 1U rackmount box from Google called the Google Search Appliance that you can hook up to your intranet and you get your own private Google search engine just for your company/organization: this is an example of bringing hosting inside to your intranet.
Now, I'm glad you like Web-based applications because they're nifty. Well, really you like hosted applications, because they're nifty. What, in particular, do you think is nifty about them? Certainly, the allure of having someone else host and maintain your software for you is sort of nifty. However, I find Web-browser based interfaces to be almost uniformly awful. Do not throw out the baby with the bathwater simply because you think FileMaker is old or antiquated. That database works, and it has your data in it already. Unless you are prepared to build a Web interface that uses either 1) Java applets, 2) Silverlight, or 3) a large amount of AJAX, the FileMaker UI is going to be light years more friendly and easier to use than anything you can build with FORM tags and a submit button. I can't count the number of times someone's taken an old, "clunky" application written in PowerBuilder or COBOL that has a very expert-friendly, interactive UI and replaced it with a "newer, better" Web interface, only to alienate 80% of the users. Ask any realtor how badly they fucked up the UI of the MLS system when it went Web.
You don't have a programmer. Even if you did, I'd still advise you to start using FileMaker right rather than throw the whole thing out and start over again. I can't emphasize this enough. Unless you have a Ruby on Rails programmer handy, don't try to use Rails. Just don't. It is NOT a 30 second job unless you have the universe's simplest database (like one flat file). If you do have one flat file, fuck it, use whatever technology you want. If there's any structure to the FileMaker database, don't throw it out until you're sure you can't do what you need with FileMaker.
Assuming you're just dead-set on making your data accessible through a Web browser, FileMaker can help you here too. Later versions of FileMaker have something called FileMaker Web Publishing. Yes, FileMaker discovered the Web, albeit somewhat late in life. There are now 3 different ways to publish your FileMaker data so it can be accessed through a Web browser - Instant Web Publishing, which is the 30-second solution you're actually looking for that doesn't require you to hire a programmer, and an XSLT and PHP option that give you more power if you want to hire a programmer.
Note that here I'm still making a distinction between hosted and Web-based: a Web-based application hosted behind your organization's firewall will be accessible by anyone with a Web browser who is also behind your firewall or on your VPN. If you're on the open Internet (not common, but still happens often these days, especially in universities) you need to secure anything you're hosting. Well, you should secure any data you're hosting no matter how, of course. Still, all the software runs on your own computers here - you're not handing your data off to Google or databases-r-us.com.
Hopefully this clears things up a bit, and lets some of the whippersnappers know that it is possible to set up a remotely accessible database application without PHP/Python/Struts/Rails/SQL/MySQL/LAMP/Postgres/Oracle.
On that note, did you enjoy FileMaker? The three hours I spent with it was like hell on Earth.
I'm not really familiar with FileMaker, but I'm a software dev-cum-web dev so I know a bit about the general field being discussed. Unfortunately, I'm not aware of any mainstream general-purpose app like the one requested in the OP. By general purpose, I mean one that allows the database to be created as desired (tables, fields, relations, etc). Pretty much every specific purpose webapp does exactly as described though.
I wanted to point out, in response to Fry, that although web-based interfaces can suck, its a tradeoff for the benefit of not having deployed/distributed clients. Many apps have the potential for hundreds or even thousands of client-users, and IT departments don't want the hastle of deploying to all those machines, as even with automated deployment systems a small percentage is bound to have problems. Updating to new versions is also easier for the same reason. Garunteed compatiblity, from a general development point of view, is also a plus (PC, mac, etc.. if you can run a browser, you can use my app).
Finally, I, like most devs on here (and there are probably lots), can build a custom app for you to meet your needs, but it wont be cheap :P. I'd say either of Fry's FileMarket solutions sound like the best way to go with regards to cost and transition (time & effort).
I don't believe it - I'm on my THIRD PS3, and my FIRST XBOX360. What the heck?
Perhaps. If it's on a shared drive that's hosted on a server running a server OS, it shouldn't be a problem. If it's residing on a Windows 2003 server, for example, and users are experiencing flaky connections, a fix may be possible. However, if it's a non-domain workgroup-type of environment, then I wouldn't expect the same kind of uptime.
I don't believe it - I'm on my THIRD PS3, and my FIRST XBOX360. What the heck?