Question

This question was inspired by one I asked almost a year ago – any-orms-that-work-with-ms-access-for-prototyping – which has recently become active again, but as an Access vs SQL Server debate.

There seem to be a lot of Access haters out there, and the main rap seems to be that it doesn’t scale well (though some people seem to have been able to make it work).

For those of you who have used both technologies, are there cases where you would use Access over SQL Server?

Why?

And how can you improve your odds of success?

For example, on a desktop app that would have one, or a small number of users – might Access be a better choice?

Or, to take the reverse tack, when should you avoid Access from the get go?

Again, why?

Edit When I say “Access”, I’d like to get feedback on two things:

1. Using just the database component (Jet/ACE)

2. Using the app development features as well (reporting, scripting, etc)

After all, there might be advantages to using some of the app dev features, if your application can live with the limitations of the DB side.

(Just for the record, I have no dog in this fight – I’m a satisfied SQLite user.)

Answer 1

I’ll answer the question you meant to ask, not the one you actually posted (you meant Jet/ACE, not Access).

Yes, there are plenty of environments where Jet/ACE is a suitable data store. I would say the main issue is how many users you’re going to have. For anything up to 15-20 users, Jet/ACE will work just fine. The only circumstances in which it won’t is if you just don’t have a clue what you’re doing. You may not have a clue if:

1. you create a single monolithic MDB/ACCDB file with both tables and forms/reports etc.

2. you try to share that single monolithic file among multiple users.

3. you wisely split your database application into front end (forms/reports/etc.) and back end (tables only), but try to share the front end among multiple users.

All those scenarios are recipes for failure, but it’s not Jet/ACE that’s at fault, but the idiot who never bothered to learn how to design and distribute an Access application.

Another common characteristic of poor-performing Access apps is to have forms bound to full tables instead of to selected subsets of records. Basically, you design your app to retrieve the minimum amount of data at a time in order to allow the user to do her work. A user editing one record doesn’t need the other 10000 records loaded behind the form, for instance.

All that said, an Access app with a Jet/ACE back end can still perform well with more than 15/20 users if those users are not in heavy data entry/editing mode. If there are mostly read-only users it’s pretty easy to support up to 50 users.

However, were I in that situation, I’d likely start urging upsizing to SQL Server. But one needs to note that SQL Server adds significant administrative overhead in comparison to a simple file on the back end. It’s easier to automate those tasks with full SQL Server than with SQL Server Express, too, so the recommendation of going with SQL Server Express is not a very good one for anyone who is not already comfortable with writing and scheduling their own SQLCmd scripts.

Security can also be more complicated. This is a consequence of there being a lot more you can do with SQL Server security, but it still has to be addressed on the front end when upsizing.

In an environment where administrative expertise is available, you can use number of users as your only benchmark for deciding when to upsize. In small offices that lack that expertise and infrastructure, it’s very often a better use of resources to stay with Jet/ACE as long as possible.

For what it’s worth, I have a dozen and a half active clients with Access apps and only two currently running against SQL Server. Of the remainder, only two of them are even candidates, and there simply aren’t very many compelling reasons to upsize them, as they are small user populations and they have no performance or reliability issues, and no significant security concerns.

That actually raises a couple of other points:

SQL Server might be a better fit even for a single-user app if one or more of these issues is significant:

1. data is sensitive and needs to be secured beyond what’s possible in Jet/ACE. Basically, if you need the data secured beyond what you could do with an Excel spreadsheet, you need a server-based database engine.

2. some applications crunch so much data that they really benefit from a server database engine, both in capacity and in the ability to hand off the database operations to a completely different CPU.

3. some applications need to be available 24/7 and no down time or any risk of the loss of even 1 byte of data is acceptable. In that case, a server-based database is advisable.

In my experience, most people vastly overestimate their needs for all three of these, and underestimate Jet/ACE’s ability to process data and maintain reliability.

EDIT: A scenario that to me is compelling for Access.

Say you have a 3-person office with no file server, just 3 PCs. Would you:

1. tell them to buy a standalone server, provision it as a SQL Server (and perhaps as a file server for them, as well), and then have them use that.

2. install SQL Server on one peer-to-peer workstation and have them use their application running against that.

3. simply use Access.

In the first two cases, there’s a lot more maintenance and administering that needs to be done (though there’s maintenance required for your Jet/ACE back end, too). Who is going to do that?

If you choose #1, where is the money going to come for for that server and the labor to set it up and the labor to maintain and adminster it over time?

If you choose #2, what if there’s no workstation that’s sufficiently equipped to act as both SQL Server and workstation?