hamofgobelgope

I know people bag on VBA, but I'm a big advocate of effectively utilizing Excels tools along side using VBA to customize where necessary. This solves the problem in your first comment (users can define their own statistical limits and methods), while keeping the simplicity of excel and its tools for other users.

The problem is that not everyone is a programmer. A "programming" tool might be great for you, but when you show it to co-workers for them to work with, they'll inevitably ask "Can I get this in Excel?". Excel+VBA allows for customization when the "complexity/ease-of-use" balance is out of sync with your needs, but to everyone else it's still just Excel.

With this, those that can program have the option to solve the problem their way, while allowing those that don't program the means to solve the problem the way their used to.

I honestly would never recommend Access as a user frontend. It's amazing how quickly Access userforms become convoluted and confusing. The only "FE" development I've done with Access is simple database maintenance tools usually only used by the developer(me) or a trained maintainer.

Also, most people are comfortable with Excel. Access userforms can scare the crap out of some users, but they're able to manipulate Excel just fine.

I was able to whip up a tool for my boss where his direct reports could log the time they spend on a particular project each day (ridiculous, I know). It's a simple Excel spreadsheet with Excels built in calendar selector, and two columns: Project and hours. Clicking a button writes to an Access database, which my boss can now pull the data straight into Excel with a couple canned reports. No one ever sees anything but Excel. I get that this may not be ideal but: 1. Took a morning to get to production 2. Quick user uptake because they're already comfortable with the system 3. Gets the job done, and my boss can still mess around with the numbers in excel all he likes

So there are use cases.

Another one that I've used successfully is utilizing Access as a middle-man to join two discrete systems within a corporation by using the Import Linked Table feature and building a join query. This way, Access does the heavy lifting of mashing two separate datasets together, allowing users to understand relationships instead of spending time trying to jam lines of data side-by-side.

This comment got long...sorry.

I've been able to make some pretty cool things with Access as the backend, and Excel as the frontend. Add a little VBA/SQL and you're looking like a rockstar. Access and Excel provide a versatile infrastructure to quickly prototype different and effective ways of using/presenting your data.