DEV Community

theBridge2
theBridge2

Posted on

If MS Access were king

If you had to convince someone their in house tool based on MS Access had a lot of room for improvement could you do it?

My journey to full stack development started in excel, then excel vba, access, SQL server with ASP.net and now SQL Server with NodeJS and Angular JS. Each step felt like a monumental improvement over the previous step and all essentially had the same goal. I wanted to organize and display data more efficiently and more effectively.

Now that I have seen the light and live in the land of more capable tools, I am having a hard time explaining why MS Access isn't a good solution. This post is an attempt to make a better case for my preferred stack.

First of all, what is the intended customers for these tools?

Intended customers

Db Purpose
Access Home or small businesses
SQL Server Medium to large businesses

Ok, but would a small business ever exceed the capabilities of MS Access (as a single user writing his own programs, I know I have experienced plenty of frustrations if not the actual limitations). If so, what limitations can we point to?

Size?

Db Db Size
Access 2 GB
SQL Server 524,272,000 GB

Yes that is 524,272 TB for SQL server. Just a little bit more than 2 GB. Even if 2 GB seems reasonable, note about MS Access here. If you delete a record, MS Access does not free up this memory.

Db Memory strategy
Access Requires compact and repair periodically to reclaim space.
SQL Server Frees memory when records are deleted

This makes the 2 GB of space a bit tighter. But how much space is 2 GB? If you are just storing text, probably plenty. If images are uploaded though, this limit may become a problem.

What about data backup and loss prevention?

Db Restore Reliability
Access Can restore from backup. Can be prone to data corruption if used in multiple user or networked environment
SQL Server Can restore entire db from backup, or rollback individual transactions or changes made to db Designed as a true client/server system to prevent stability and corruption issues.

Why is access prone to corruption?
MS Access's underlying technology is called JET for Joint Engine Technology. JET is also used in Visual basic and SQL Server Express. The key with JET is that it is based on the concept of file sharing. If multiple users are trying to access the same data, they will both get sent the entire set of data. Two challenges arise from using file sharing:

  1. How to make sure the two users don't edit the same data
    Answer to this is by employing record locking. Optimistic locking and pessimistic locking are the two approaches used. Staying out of these details for now, ultimately this can cause conflicts, failure to update data and even data corruption.

  2. Since the entire file or table is shared, performance can be slow on the network. Limiting number of transactions, users, or amount of data shared is required to keep performance up.

Performance summary

Db Design Intended use Network Traffic
Access Server sends entire set of data for every request; client does processing Limited number of users, limited number of individual transaction edits Lots of overhead since for EVERY request the entire data set is sent
SQL Server Server does processing and sends only relevant information over network to client 24/7 applications with high number of transactions and high number of users MUCH lower than Access. Only sends the specific information the client requests

Database Design Limitations

Ok, so what about just setting up a database? Isn't it much easier to use MS Access's drag and drop capabilities? Is there any design limitations to using MS Access over SQL Server? If you are ok with workarounds, the limitations of Access are not as pronounced as I expected. Two key things:

  • If you want to do a full outer join, this is technically impossible in MS Access but you can get around it by using a LEFT JOIN, RIGHT JOIN, and bringing them together with a union.
  • Sometimes MS Access performance issues require you to split up a database into a front end and a backend database. I have read of people using even more than two linked databases for performance improvements.

If you are motivated to figure out these workarounds, I would argue you are probably motivated enough to learn SQL and SQL server (or some other Relational Database Management System (RDMS)) . Perhaps that is a better investment in your time.

Cost

This one turns out to be more complicated than anticipated. The assumption here is if you are comparing the price of Access vs SQL server you are probably a small company. Let's answer this for a company with 25 employees assuming that the application being developed is an internal tool only.

Db Cost Total Yearly cost
Access $20/user/month for Office 365 $6,000 (25 users * 20/mo*12 mo)
SQL Server Standard Edition ~2k/core using 1 core for standard edition + client access license (CAL)/user * 25 users $2k + CAL cost(?) = < $8k (?)
SQL Server Enterprise Edition $/core with no client access license required ~$8,000 (1 core) - ~$13,750 ( 2 core pack)

As we know by now, SQL Server is designed for many users doing lots of transactions a day. As a result the number of cores is an important factor (and Microsoft has it priced that way $/core vs. $/user). SQL server pricing is quite complex. I wasn't able to figure out the exact price for the client access licenses needed for the standard edition. The enterprise edition pricing does not require the CAL and is therefore independent of the number of users.

For MS Access, the # of cores of the "server" (or machine running the database) isn't relevant because all the processing is done on the client machine.

Let there be no confusion, SQL Server pricing is complicated and probably requires a call with Microsoft to make sure you have the correct license. I think I have distilled it here, but if it were me making a company decision on this, I would call and ask about pricing, then keep googling to make sure I understood all the nuances.

Summary

So if MS Access were king today, being used for anything and everything, what would the world be like? We would probably have a much less world wide web. Since MS Access doesn't support many transactions, things like twitter, facebook, and even instant messaging would not be possible. Even the early chat message program of 1996, Mirabilis's ICQ, had a client server relationship. Trying to write just a simple global chat program like ICQ appears to be an impossibility if your only tool is MS Access.

An Aside

Yes I admit, I am heavily biased against MS Access since I ran into its limits writing programs for myself. I am hesitant to say though, there may be places for the program still today, I just don't want to have any part in developing or maintaining them.

Top comments (7)

Collapse
 
camilocaquimbo profile image
Camilo Caquimbo Tabares

An usual solution I have seen is work with an open source DB like Mysql or Postgres and Access like frontend

Collapse
 
aaronkempf profile image
Aaron Kempf

I'd love to see more people using that setup. I miss the good old days of using 'Access Data Projects' they allowed Access forms and reports to be directly created against MSSQL without all the nonsense of connection strings. One simple connection per .ADP file. THAT is how Access should be designed, but the kids who use Access couldn't figure out how to do it. I argued for years. It breaks my heart, but I would MUCH rather live in the tech world from 2000-2012 compared to the tech world of today.

Collapse
 
thebridge2 profile image
theBridge2 • Edited

Wow, interesting. I suppose you have to start with what you know and go from there. If nothing else it seems like more "standard" solutions will be easier to get help from the web when you run into issues and easier to maintain in the long run if multiple people are involved. I try to keep an open mind to why the non-standard way might have value but sometimes it is harder than others to find it.

Collapse
 
aaronkempf profile image
Aaron Kempf

You say that CALs aren't required with Enterprise edition? I don't think that is true.

Also, you say that Jet engine is used with SQL Server Express? I don't know how true that is. The topic is a lot more complex than it was a few years ago. There are many different ways to create SQL Server databases. I think that MS SQL Server Express is the best choice for MOST people.

Collapse
 
jlzaratec profile image
Luis Zárate

One combination interesant is use Access in the Front End and MySQL/MariaDB in the Back End using ODBC and Data Access Disconnect :D

Collapse
 
aaronkempf profile image
Aaron Kempf

Yeah. But open-office and Libre-Office from what I understand, they allow a true Client-Server solution. JUST LIKE WHAT ACCESS DATA PROJECTS USED TO OFFER. It wasn't JUST ADP that was a huge deal, the OTHER side was 'Data Access Pages'. I implemented DAP and ADP all OVER the Seattle area for many of the largest companies in the world.

Office Web Components was from DAP, and that was the COOLEST reporting that I've ever seen. It was great, until OWC stopped being included with SQL Server installation.

I miss the good old days of storing spreadsheets and pivotTables in a SQL Server database. I've worked on systems with 70k distinct reports based on OWC / DAP. It was SUPER popular back in the day. I wish I was still using that combination today.

Here is more about the options in LibreOffice / OpenOffice. From ChatGPT

Yes, in LibreOffice you can use either MySQL or PostgreSQL as the backend database and design your tables and queries directly in those databases. LibreOffice Base allows you to connect to external databases like MySQL or PostgreSQL via JDBC or ODBC drivers. Here's how it works:

Tables and Queries

  • Connection: You can connect LibreOffice Base to MySQL or PostgreSQL using the appropriate drivers (JDBC or ODBC).
  • Table Design: Once connected, you can create and manage tables directly in the backend database. You can design tables using SQL commands or use the graphical interface provided by LibreOffice Base.
  • Queries: Queries can be written directly in SQL or using the graphical query designer. These queries will run against the connected MySQL or PostgreSQL database.

Forms and Reports

  • Forms: Forms in LibreOffice Base can be bound to tables or queries in your MySQL/PostgreSQL database. You can create forms using the form wizard or design them manually. The forms will then allow you to input or view data that is stored directly in the backend database.

  • Reports: LibreOffice includes a report generator (Report Builder) that can be used to create reports from the data in your MySQL/PostgreSQL backend. Reports can be generated based on the data in tables or queries and can include dynamic content.

Things to Keep in Mind

  1. Performance: Directly connecting to MySQL or PostgreSQL can introduce some performance overhead depending on your network and database size.
  2. Driver Setup: Make sure that you have the correct JDBC or ODBC drivers installed and configured correctly.
  3. Database-specific Features: Some database-specific features (like triggers or stored procedures) may not be directly accessible through LibreOffice, but you can still use them by managing them in the backend.

Would you like any guidance on setting up the connection or designing specific components?

Collapse
 
thebridge2 profile image
theBridge2

It seems the trick with building new tools is balancing capability and interface for people who are at best power users with those who are deeply experienced in the technology. It does take time to learn a technology deeply but it is so rewarding and so much more powerful.

Seems those small to medium businesses are going to be a pile of the easy to use technologies, duct taped together until someone with more expertise comes in and makes sense of it.

Definitely a sad day when "advancements in technology" make the product worse!