Hi,

I work in a school and we have recently contracted a company for our School Management System (offers a MS Access client front end as well as web portals to a SQL Server backend). It turns out that the system isn't very user friendly and quite buggy (I think largely as it uses MS Access front-end for much of the work). Also this system is limited for us as we are moving to Macs soon and we will have issues using the MS Access interface.

I have just come across FileMaker and see that it is cross-platform (Mac & PC) as well as seems to easily offer a web interface with multiple group security levels.

I was hoping somebody with experience with FM could let me know of its limits regarding DB size, and if there are certain "bugs" or annoyances that come with using it (as I have found with Access in the past). Specifically:

1. In addition to normal data, we would probably upload up to 10MB of documents to the server each day (this would be for about 200 days per year). We would want the server to sustain for quite a few years without lag and other issues... would FM handle this well or would I need a separate MS SQL backend?

2. We could have up to several hundred users interfacing online at any one time. Could the online connectivity of FM handle this?

3. Access has issues with their forms, like the way you move between records sometimes conflicts with new records, causing system freezes. Does FM ever experience these issues, or system freezes?

4. If I start with FM (frontend and backend) and later migrate the backend to SQL Server due to growth, would it be easy to do? I worry that I would have to 1. recode the SQL and 2. have a major task reconnecting the old frontend with the new backend.

Thanks in advance for any advice.

is it bugs in Access or bugs in the Access application?
Ive never had this system freeze you report, nor have I heard of it as a problem elsehwere. so on the face of it it sounds like its the application design that is flaky

if you have contracted for a School Management system from a specific company, then unless they do a dual version that runs on Filemaker as well then you are wasting your money.. although whether the waste is on Apples or the Access system is a moot point. granted you probably can run Access successfully inside a windows environment on an Apple platform.. but why.. means you are paying for two OS licences, negating (if any) savings.

if the designer of your admin system is using a SQL server back end then you will have the same connectivity options under Filemaker. if you are using a JET back end for the system then you will have the same problems if you switch to Filemaker... both use the file server model to store data rrather than the server model.

if you have over 100 people accessing the system concurrently then you should be using a server backend.. doesn't matter if your app is in Filemaker or Access, file server systems struggle with that sort of load.

I've used Filemaker in the past (around 6..8 yeears ago, so it may well have moved on), however my impression was that its a great product but its aimed at more naiive / simple applications than Access. Access is a bit of a chameleon its can do basic naiive applications it can do complex multi user applications..it all depends on what you use, and how you connect to the data.

the mroer data you have in file server systems (whether they be Access, Filemaker, Open Office's dbase and so on) the more laod you are putting on the network and the file server. byt deifnition you are stressing the system more than it need or should be. Access is good for around 2 Gb, newer versions of JET 2007/2010 may have broken this barrier, I woudl expect Filemaker to have simialr inherent limits

Vanilla Access is great for say upto 15..30 users, after that the JET data engine and file server model starts to cause problems. after that you need to shift to a server back end, use unbound controls and that involves a lot more programming effort.

Your question is old, so this advice might be pointless. FileMaker has grown in capacity over the years and in version 11, can have a file size of 8TB, 1 million tables per file, and 64 quadrillion total records per table. You can see many other limitations at their specification page at: Technical specifications of FileMaker Pro 11 and FileMaker Pro 11 Advanced | FileMaker

Those things aside, huge files with thousands of users and transactions happening at the same time are still in the realm of large SQL databases like Oracle, Postgre, DB2, MS SQL Server, etc. But most needs exhibited by school database needs fit well within FileMaker. The Advanced FileMaker server used to have a limit of 1000 concurrent users, but it is now unlimited by license and limited only by your hardware and bandwidth. Keep in mind this is for FileMaker clients and web connections are limited to 100 concurrent connections.

The reason you would choose FileMaker is because it tends to be easier to develop which is useful if you don't have full time IT people to help you make your database. FileMaker in a single product that takes care of the user interface, reports, web, and database backend. And FileMaker does a pretty good job of keeping this fairly simple. Not that you can't get more complicated, but learning Access and managing MS SQL Server database is a bigger learning curve. Now if you already have full time developers who know those tools, then they might be a good way to go and you know SQL Server is very scalable.

FileMaker has the ability through ODBC to read SQL databases and that is a good way to enhance a FileMaker solution. This works well if you are primarily making FileMaker databases and only need some SQL access for your school management system data. FileMaker is not a native SQL front end tool and will not perform as fast as those tools will. If you plan to create new files and tables in FileMaker and have links to SQL Server, FileMaker is a good solution. If you plan to have all your data in SQL Server, then you will be better off with a SQL front end tool.

FileMaker is known for its ability to easily create very good looking user interfaces and reports. The tools it has lets it be a good Rapid Application Development Tool. Traditional tools on the SQL side of things get much more complicated. Personally I am not a fan of Access. If you need to write a front end with a SQL Tool, I would look at Servoy instead of Access. But that's just my 2 cents.

As previously mentioned, FileMaker supports ODBC so that FileMaker can read MS SQL Server databases as well as others like Oracle and MySQL. This also works the other way. Your School Management System SQL database can make SQL connections to your FileMaker data via the ODBC connection too if that is desirable.

One last useful tool FileMaker has is the ability with a single click to turn on secure client/server connections so that all of your data is encrypted using triple DES encryption. As security becomes more of an issue, having a one-click encryption solution sure is nice. And there are no certificates to manage or anything like that. Having encryption and combining it with authentication through Active Directory is pretty much a corporate standard now and I assume schools are having to step up security on personal information too.