Fog Creek Software
Discussion Board




Filemaker And coworkers

Im a college teacher. We have been planning to build a little intranet for our staff for a while and since im the guy with the datamodelling/web app skills i've been put in charge of the project.
The primary focus of the app will be an inventory database where all our hardware and software is registred. Simple stuff.
The next thing is to tie the inventory to the scheduling so that the tech support can easily find out when and where certiain hardware and software needs be installed.
No problemo so far. I could do this in less than a week with ASP or JSP. Approx. 30 ppl will use it.

People around me are pushing Filemaker, praising its ease of use etc. One of the tech support guys in particular, is talking about how he could set up the inventory thing in a matter of hours.
And to be honest I am a bit afraid that he will do just that and devote a load of time in to putting all the data into the database, with a datamodell I cant expand upon. And it feels a bit like he is invading my territorry. Yet I dont want to hurt his feelings either... Thoughts?

And in any case, would filemaker be a good tool for this kind of job?

Eric DeBois
Friday, November 01, 2002

You likely don't want to use Filemaker with something 30 people are going to be using.  If you're going to be going above 2 or 3 users then you need to get FileMaker Server.  And Filemaker Server isn't intended to go above 10 or 20 users, if I recall, per Filemaker's own documentation.

Also, Filemaker isn't an SQL database, so you're right that it's not expandable at all.

I would say that it's probably a good job to use MS Access for.  If your tech support guy is savvy, he could build it just about as quickly in Access as in Filemaker, and you'd also be able to program against the database in your web pages if you wanted. 

Maybe you could even design the table structure yourself and give him a shot at making something usable in Access before you spend time coding your own solution.  Time he spends getting data into the database won't be wasted, since you'll use the same back end even if he is unsuccessful at creating the Access front end.

All of that may be irrelevant, because he's probably just a power user who's familar with Filemaker but not with Access.  Or your users may not have Access licenses. 

If the Access licensing is a problem, you could just get a copy of MS Office Developer (around $500), which lets you make runtimes of the front end that can be freely redistristributed.  This would still be cheaper than getting a copy of Filemaker Server (around $800, if I recall).

Herbert Sitz
Friday, November 01, 2002

Whoops, after reading your post again I wonder if you were planning on using Filemaker to web-enable the database over the intranet.  You can do something similar with Access (using its Data Access Pages), but to use them you're required to have Access licenses for each client computer, although you don't actually have to have Access installed. 

Probably not a great idea to use Access in that case.  But if the main thing is just to get networked access to the database, then Access would work well and you could forget about the intranet part.

Herbert Sitz
Friday, November 01, 2002

Design and build it yourself. The tech support guy probably won't understand relational design. Access and ASP is a simple, robust technology and ideal for this sort of project.

BH
Friday, November 01, 2002

Good Info.
We have MS Office on every darn machine (300 +).

The most logical choice would then be to build with Access. This allows for both a plain access front end, and building ASP pages for it if needed. Besides, we have quite a few people who know access pretty well here which is good in case im not around. (Which was the reason I canned my original highly scalable JSP/MySQL plan)

Come to think of it, not building with access would be pretty stupid.

The info on the filemaker server is crucial and pretty much disqualifies it for this job. *sigh of releif

Thank you fellas

Eric DeBois
Friday, November 01, 2002

I should amend what I've said to clarify that, yes, it is possible to run Filemaker Pro with 10 or 20 users without using Filemaker Server.  It's just not recommended.  For example, you can read some info at www.ebase.org, regarding ebase, which is a freely available nonprofit management tool based on Filemaker.  They say,

"6. Can ebase 2.0 be used on a peer-to-peer network?
Not reliably. While FileMaker can be hosted on a peer-to-peer network of up to five computers, we do NOT support this approach. The potential problems inherent in Filemaker's peer-to-peer networking architecture will cause you to lose data. We strongly recommend the use of Filemaker Pro Server in all multi-user installations of ebase."

And I've heard many stories of frequent data corruption problems using multi-user Filemaker Pro.  (Makes Access look bulletproof by comparison.)  Also, the Filemaker Server version of the database isn't a whole lot better.  It's still a fileserving database, not a true database server.

Filemaker has its uses.  But I wouldn't count serving a 30-user database among them.

Herbert Sitz
Friday, November 01, 2002

Excel might be adequate. No programming required.

pb
Friday, November 01, 2002

I shudder at the thought of putting data in Excel.  It allows far too much flexibility, meaning the potential for users to utterly hose your app is way too high.

FileMaker might be OK for storing data, but I've never liked it (I couldn't get past the lack of a real programming language), and its practice of storing views with data is just weird..  Access/ASP is probably a reasonable choice (though ASP is not particularly pretty).

Also, if you wind up needing it, you can probably pick up a copy of Office Developer Edition for less than $500.  I got it for $339 from ProVantage last year.

Sam Gray
Friday, November 01, 2002

Don't worry about what database to use until you have a model to use it with.

Concentrate on developing the database model, (my usual trumpet blowing of ORM here), then choose the right platform for the job.

Then if things change and its no longer the best platform you can use the model again.

Simon Lucy
Saturday, November 02, 2002

I think at the end of the day, one kind of has to use the tools one knows. You only need to avoid using a tool if it is not the right one for the job (but you still know it!!).

I can’t imagine these people choosing FileMaker over your suggestion of using a web application? What gives?

I am sure a better debate can even be brought up for FileMaker VS ms-access. FileMaker has improved its connectivity to databases by quite a bit recently (but has always been one of its shortcomings).

You have a lot more choices with ms-access. Heck, you can use ms-access with the free open source MySql database if you want (if you do this, then you can’t use the nice diagramming tools to manage and build table relationships like you can when you use access with sql-server (or JET for that matter). Being able to point and click to manage your relations is very nice feature, and I wish this stuff could work with other databases then sql-server.

As mentioned, ms-access also has a royalty free runtime that lets you package the application as a standard windows install. That means the users can install the application like any other windows product and they don’t have to have ms-access. In fact, they don’t even have to know that is it written using ms-access.

I would go with the latest version of office-xp. (since the users don’t need access installed anyway). In fact, I would get office developer. It includes a ton of goodies like:

Package and deployment wizards (create royalty fee installs)
Visual SourceSafe Integration
You get both Workflow designer for SQL, and you also get the developer version of sql 2000 server.

You also get all kinds of other stuff like Frontpage 2002, and even Exchange server is included. (there is just tons of stuff included now).

I mean, if there is no choice, then ms-access might be fine, but it seems that you have the ability to create a web based product.

How could anyone consider anything else?

Web based interface can be a bit weak, but it depends on the application. I have been a fairly harsh critic of web based software. However, it is getting much better, and the connectivity of web stuff is what is selling me right now.

No client side maintenance is required with a web based system either.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

Albert D. Kallal
Saturday, November 02, 2002

I've had a fair bit of experience supporting applications written for the Access runtime, and your results may vary.  If you can do the install yourself or can afford to spend time walking your users through the install, it can be a good way to go.  However, I've seen enough installation problems on PCs that already have a version of Access on them that I wouldn't advise it for a developer who doesn't want to be bothered by mere users.  (=

Sam Gray
Saturday, November 02, 2002

>>However, I've seen enough installation problems on PCs that already have a version of Access on them that I wouldn't advise it for a developer who doesn't want to be bothered by mere users. (=


The package and deployment stuff for ms-access is no where near as good as say VB.

However, the new XP one is a good deal better.

The solution here is simple:

If you have a large number of installs and distributions, then I would suggest you purchase some sagekey scripts. They make scripts for both Wise, and Install shield

That means one has to purchase Wise or Install-shield installer, and not use the p & d for office.

When you use the scripts from Sagekey, then all of the problems of other versions of office, and browser stuff is eliminated. They are highly recommend, and if you want trouble free installs, they are the way to go.

Their installs work flawlessly, and don’t break anything else on the pc.


Check out:

  http://www.sagekey.com/

Albert D. Kallal
Saturday, November 02, 2002

I don't quite see the point of using a tool (FileMaker) which, in its basic form, is not built for parallel write operations, and requires extra $ for its multiple-access version. Especially since you mentioned that you want to develop this application as a web application.

Why not simply use a free, open-source client-server application like MySQL, PostgreSQL, or Firebird Interbase? Are there features in FileMaker or MS Access that those tools don't provide that would justify shelling out $ and using a proprietary tool?

Fred.

Frederic Faure
Monday, November 04, 2002

Why doesn't the college teacher give it to the college students as an assignment and get his work done for free?


Monday, November 04, 2002

"Are there features in FileMaker or MS Access that those tools don't provide that would justify shelling out $ and using a proprietary tool?"

Well, Eric said in his second post that all of the client computers already have Access.  So the question becomes whether there's any advantage to using Access over a web scripted front end to one of the open source databases.

Access has definite advantages in terms of development time and the quality of interface you'll get over a web app.

I think Jet is probably up to the task as a back end for this job, but if not someone has already pointed out that you could write an Access front end to one of the open source databases (using ODBC).

Seems like it would be silly not to leverage the development advantage Access gives, especially when all the client computers already have Access installed.

Herbert Sitz
Monday, November 04, 2002

For read only access to Access Web Pages there is no need for the client to have access installed. He simply sees the page as a normal HTML file.

I would use Access and leave the Access database on the server. You're unlikely to have 30 people accessing it at the same time, and even then it should take it. If they only need read only access then let them see the web pages you have created, and cut down the number that are connecting to the .mdb file directly.

One thing though. Do set the Access file to compact on close as ballooning .mdb files are one of many MS mysteries. And I suspect you will need some way of forcing users to log off from the database, or forcibly close down their computer, to allow for this.

Stephen Jones
Monday, November 04, 2002

If you guys think Access (of all databases!!) is the tool of choice, good luck. But seriously: if Access can handle it, FileMaker will be more than adequate! It'll fly circles around Access......

FileMaker 6 is very capable, very powerful, has lots of XML and web publishing capabilities, is cross-platform (Windows / Mac - if that ever should be relevant), and it's a LOT easier to use and deal with than Access.

Also, I don't assume those 30 people will constantly be online concurrently, right?

If you do feel like you have to go with a "real" SQL database, use FireBird, the Opensource version of Interbase - excellent stuff, very high quality, and FREE. Access it from any language, Delphi, VB, C++, Java and all, and it's absolutely rock-solid (used by several 911 dispatch centres). http://www.ibphoenix.com

Marc

Marc Scheuner
Friday, November 08, 2002

Marc, can you please tell us what you don't like about Access. To say (of all databases!!) suggests either that you know soemthing everybody else doesn't, or are simply mouthing off.

Stephen Jones
Friday, November 08, 2002

Like someone said earlier on. Concentrate on the data model.

Nothing pisses me off more than having to maintain or worse yet extend a database designed by someone who thinks access is a super spreadsheet.

We can discuss the pros and cons of the different databases, but if your tech support dude scr*ws up the data model, which is easy to do with access... (GUI tools and the spreadsheet look very dangerous with inexperienced 'DBMs'), then even if you implement on Oracle, you will still be stuffed.

tapiwa
Sunday, November 10, 2002

Please, forget all this toy-alike-software like Access or Filemaker.
We're talking about Databases, not about easy filesystems pseudo-databases.

Try with any good SQL compliant server like PostgreSQL, Firebird, MySQL.
If you want good ACID features, transactions, stored procedures, triggers... go on the two firsts ones. If you want a more relaxed system , go on MySQL.

I'm tired of listening about Filemaker being a Database Software, ha!! don't make me laugh

xavier
Wednesday, August 25, 2004

*  Recent Topics

*  Fog Creek Home