Access vs Comercially available databases (2 Viewers)

You're being cynical. If you feel Access is so insecure, then why do you develop with it, or even use it?
Although the system is definitely insecure, it offers a really efficient way to build UIs quickly. Sure, there are limitations, and the UI doesn't exactly meet security standards. But it's still functional enough to get the job done. It's a usable UI in the sense that it lets you interact and perform a variety of tasks, but let's be clear: it's nowhere near a robust, safe environment.

Just think about it: you're basically hoping your users don't do anything malicious. And honestly, do you really think there won't be any bad actors eventually? I mean, think about it: what if some users aren't supposed to see sensitive stuff, like company profits or individual salaries? What if they're able to view how much vacation a certain person is allowed to take, payroll details, or confidential project budgets? Think: subcontractors.

But it doesn't stop there. What if they gain access to even more critical data, like HR files, customer credit card info (yikes!), or system admin passwords? Imagine if private email communications, client contracts, and trade secrets were exposed. What about internal audit results, sensitive medical data, or legal documents that should remain strictly confidential?

Then there are things like personnel evaluations, marketing strategies, intellectual property, or even database connection strings that could end up in the wrong hands. What if employees can access financial transactions they shouldn't see, or view projects in development that haven't been announced yet, where they were not included? Even worse, what if someone gains access to the company's entire client list, email marketing campaign data, or product pricing models to replicate the whole business somewhere else?

The list goes on, and it's a serious concern. With a system this insecure, it's hard to feel safe knowing that so much sensitive data is just waiting to be mishandled, intentionally or otherwise. Wanna consider a lawyer? you better do.

On top of that, Access can be pretty unpredictable when you try to create custom workflows or add features to components that really need them. What works smoothly in one scenario can suddenly break when conditions change, and often, it's in ways you don't expect. These issues can be tough to predict because the underlying causes are often hidden, undocumented, and deeply ingrained in how the system operates. This lack of transparency makes troubleshooting a serious headache, since the root cause is rarely clear.

Despite all the issues, we usually find workarounds, like using MSSQL to some extent. The core system may be unstable when pushed beyond its basic limits, but there's often a temporary fix, even if it feels like a quick patch. Ultimately, you're relying on hope that things will go smoothly. As a developer, though, you can't ignore these shortcomings, they're always there. But then again, more robust systems require more robust specs and a significant extra development time, so, it's a trade-off.
 
I agree. If you're going to give them access that means you trust them.
Just because you trust them doesn't mean you need to leave gaping security holes that can easily be closed.
Just think about it: you're basically hoping your users don't do anything malicious.
Your Access FE probably locks the users out of design view on anything and doesn't give them options like - delete all tables? But are you willing to allow them to use their SQL Server credentials outside of your Access application is the question?
 
Just because you trust them doesn't mean you need to leave gaping security holes that can easily be closed.

Your Access FE probably locks the users out of design view on anything and doesn't give them options like - delete all tables? But are you willing to allow them to use their SQL Server credentials outside of your Access application is the question?
Grant them EXECUTE permission only on the specific stored procedures they are allowed to use, problem solved In some cases with read access to the tables.
I don't particularly like SA's as I want the database to be aware of who is who.
 
Last edited:
Grant them EXECUTE permission only on the specific stored procedures they are allowed to use, problem solved In some cases with read access to the tables.
I don't particularly like SA's as I want the database to be aware of who is who.
You can grant them DBA privileges and the db will still be safe because none of the authorized users would know how to, or would dare mess around with something they're not supposed to touch. The db audit log would reveal who did what, when, and they would lose their jobs and face criminal charges.
 
none of the authorized users would know how to, or would dare mess around with something they're not supposed to touch.

That is one of the most tenuous assumptions you can make.

When I was doing U.S. Navy work, one of the Senior Chiefs made it clear to all users of our databases that we had a ship waiting at the port of embarkation that still had the equipment required for keelhauling. Which would be doubly bad because besides being an easy way to drown, it would be through Mississippi River water, which isn't necessarily that clean.
 
Anyway, it's a very common method and it keeps people's database-identities separated and individual, as they ought to be. The extensive use of service accounts leaves you outside the 'know' when it comes to who did what - and in that case, YOU'RE relying on your FE to audit who did what and log that, but if they do something outside the db .... You'll never know.
 
Then you can't build an application using bound forms.
That is true, my suggestion would be best on an unbound form, but at least it avoids using service accounts where nobody knows who did what EXCEPT your fe app
 
The extensive use of service accounts leaves you outside the 'know' when it comes to who did what
I never suggested using a single account. All users should have unique accounts. They just shouldn't know their credentials.
 
Your Access FE probably locks the users out of design view on anything and doesn't give them options like - delete all tables? But are you willing to allow them to use their SQL Server credentials outside of your Access application is the question?
I don't know what you're talking about.

Here's an accde file viewed with the notepad
1754853451373.png


Here's an accdb file viewed with the notepad
1754853638078.png


Stuff isn't very safe here, but hey, I built this in like 10 minutes, that's valuable
 
Anyway, it's a very common method and it keeps people's database-identities separated and individual, as they ought to be. The extensive use of service accounts leaves you outside the 'know' when it comes to who did what - and in that case, YOU'RE relying on your FE to audit who did what and log that, but if they do something outside the db .... You'll never know.
That's why Windows Authentication with no service accounts is the preferred method for connecting to SQL Server, Oracle, PostgreSQL, and other db servers. If you can't pinpoint the culprit, then you have to detain all users and hang them upside down by their toe nails until someone confesses.
 
Last edited:
That is true, my suggestion would be best on an unbound form, but at least it avoids using service accounts where nobody knows who did what EXCEPT your fe app
Web apps use stateless unbound forms, but Access doesn't. Service accounts should be avoided because it's difficult, or impossible, to trace who did something.
 
Last edited:
That is one of the most tenuous assumptions you can make.
Me: You can grant them DBA privileges and the db will still be safe...
I kno it was a flimsy weak statement. I was being sarcastic, but users have to be trusted to a certain extent, without crippling their productivity.
 
Last edited:

Users who are viewing this thread

Back
Top Bottom