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:
Much of the discussion on this thread has been, quite sensibly, about security issues; however, the initial question was far more fundamental - can the commercial available offering do the job that the current system does?

The simplest answere I'd give is to ask the people who use the current system what they are willing to do without? I virtually guarantee it will be nothing! And is it the user's or the managers driving the change? If it is the latter ask them how much they are willing to pay (in perpetuity) to have the commercial system customised?

My (bitter) experience is that it will at least treble the up-front cost!
 
Much of the discussion on this thread has been, quite sensibly, about security issues; however, the initial question was far more fundamental - can the commercial available offering do the job that the current system does?

The simplest answere I'd give is to ask the people who use the current system what they are willing to do without? I virtually guarantee it will be nothing! And is it the user's or the managers driving the change? If it is the latter ask them how much they are willing to pay (in perpetuity) to have the commercial system customised?

My (bitter) experience is that it will at least treble the up-front cost!
And from the sound of it, they already have a working system.
 
So document your Access app well, including technical and end user documentation, and bring another Access developer, or firm, on board. Explain to management the pros of your Access app, and the cons of COTS software.

You can also integrate instruments with your Access app.
Once again, I stand by my earlier statements. Defend your existing app for all of its merits. If they're worried about you being the only one that knows how to maintain and run the app, there's plenty other experienced Access developers available.
 
Yes, it was to you. If you use service accounts you don't know who did what unless your FE logs it
I never said to use service accounts. No one ever asked me what I do, you all just poo-pooed the issue so I didn't bother.
 
Much of the discussion on this thread has been, quite sensibly, about security issues; however, the initial question was far more fundamental - can the commercial available offering do the job that the current system does?

The simplest answere I'd give is to ask the people who use the current system what they are willing to do without? I virtually guarantee it will be nothing! And is it the user's or the managers driving the change? If it is the latter ask them how much they are willing to pay (in perpetuity) to have the commercial system customised?

My (bitter) experience is that it will at least treble the up-front cost!

I've told a part of this story before, but it becomes relevant again relating to the fundamental question, as DickyP reminded us. The question is "roll your own" vs. "over-the-counter."

The USA uniformed military services in 2009 wrote a specification for a new personnel management system that was supposed to unify all of the military services, because at the time, each service had its own separate personnel system - and most of them had a separate system for active military vs. reserve military. That meant that EACH SERVICE had to build transactions for the "purple" services (i.e. all services combined, or "joint services") could talk to the civilian side of military management - like Defense Financial Accounting Systems (DFAS) and other agencies that had to serve ALL of those services. My Navy Reserve personnel management machine (which would have been replaced... except read the next paragraph) talked to 18 different agencies that were civilian and cross-service in scope.

The intent was to buy OTC and then get the vendor to do any required customization. That requirement WAS in the spec. What happened was, first they had to quell the not-so-quiet rebellion. Army and Air Force were almost the same in personnel rules and they were ready to go along with the idea as long as THEY didn't have to adapt to too many changes. (Change what WE were doing? No, let the other guys adapt to us.)

Navy, Marine Corps, and Coast Guard? You would think someone had kidnapped their youngest children into overseas slavery. After several presentations, PeopleSoft won the contract, beating out ORACLE by about 1%. (The delicious irony is that before the project was over, ORACLE blithely BOUGHT PeopleSoft.) PeopleSoft had these "personnel support" modules that if you had specific types of employees, it was like a library of handling code. Analogous but not identical to having specific data types and individual rules to handle each type - except a LOT more complex.

As each service dug in their heels over specific features, it got crazier. For instance, of all of the services, the U.S. Navy Reserve was unique because Navy Reservists have contracts that, if breached, would release the reservist of his/her military obligations. That's right - Navy Reservists are technically NOT enlisted personnel. Any other service would discharge a reservist with a gripe - probably with a less-than-honorable separation. But not for the Navy Reserve. Anyway, after seven years and 10 billion US dollars, it got shut down due to cost overrun after cost overrun because none of the services was willing to budge on most of their core requirements.

In detail, what happened is that "over-the-counter" morphed into "roll-your-own" because the OTC software was estimated at only 12% compliant with the actual requirements and NONE of the services would adapt. So ... core software change orders for the non-compliant 88% abounded. BUT it was done with contractors doing the retrofits, upgrades, remodeling, and customization. And these change orders were full-traffic time-and-materials costs, no discounts. The best they could do before the plug was pulled was that a personnel cycle that was supposed to occur every 24 hours took a couple or three days per cycle using the fastest multi-threaded CPUs available on the market. (Ironically, that was when ORACLE also made processors.) If there was a leading, bleeding edge CPU available at the time, they tried it.

Thus, when Congress wanted to upgrade personnel management in a standardized way, the intended users of the proposed system were opposed. And as a result, we STILL have almost the same exact system that was used before the DIMHRS project was started. "Almost" - because since DIMHRS started and subsequently tanked, the U.S. Space Force came into existence - another uniformed regular service and reserve units - 12 groups instead of 10.

The moral of the story? Change orders are like vampires. They suck your company's blood until it is dry. And buying OTC almost invariably leads to change orders. If your company has the ability to "roll its own" it might end up cheaper in the long run.
 

Users who are viewing this thread

Back
Top Bottom