Introduction - Riven Skaye

[RivenSkaye]

I'm Riven, a somewhat fresh software engineer - a couple years under my belt at the time of posting, but not all that much as of yet.

My contact with MS Access is mostly limited to my paid employment - I have no desire to do more with it for personal projects other than contributions to some libs and utils that might one day help us migrate more of the data away from Access as a DB. For front-end stuff it's fine, but I'm not a fan of any setup involving a single-file DB on a network share...

Personal interests with regards to programming are quite varied. I have a passion for A/V stuff and doing cursed things making things work that other people don't want to put as much effort into. Examples are making memory-safe shmem-like interfaces on Windows (avoiding TCP leaves you with a single option that requires a lot more boilerplate than its POSIX equivalent and Linux's extensions to that) and dabbling in project and env management (kinda like package management, but with isolation from the rest of the system). Besides programming my interests start to vary wildly. From archery and horseback riding, to home reno stuff and even just spending days on end absorbed in books or story-heavy games.

As for my work, I'm currently busy maintaining software that has faithfully served the company for almost a decade, built around an MS Access DB w/ FE that has been in use since '97. As we're looking to slowly move away from Access for the DB part, I'm trying to keep new things solely in the new DB through linked tables, and we're slowly moving things over in order to get more stability out of the infrastructure. Every once in a while someone will have their cursor idle on the wrong row with some consequences I'm sure a lot of people here will know. Besides the MS Access stuff I'm busy maintaining and rewriting some internal use software for inventory and shipping management. Piece by piece we're moving to more modern tech in a few places!

 

[Jon]

Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!

 

[The_Doc_Man]

Hello, Riven, and welcome to the forum.

I understand your desire to migrate away from Access. Just don't sell it short as a way to design a DB's general concepts and then migrate it to a more secure and robust back-end SQL engine. Makes a GREAT staging platform. And it makes a great front-end for many robust back-ends.

 

[theDBguy]

Hi. Welcome to AWF!

 

[RivenSkaye]

Hello, Riven, and welcome to the forum.

Makes a GREAT staging platform. And it makes a great front-end for many robust back-ends.

I absolutely agree with both of those. But after more than 25 years, it has definitely passed the point of "staging" and we're currently just hitting some limitations with Access as a DB. By no means do we plan to remove it as office front-end or anything. And these limits would've definitely been met with something like SQLite as well, we really just need a DB server at this point to reduce conflicts and overhead and sane management of datatypes with a bit more control over the underlying structure for our data

 

[The_Doc_Man]

"Sane management of datatypes"... good luck with that one. Let's hope you don't have any managers who are also database manager wannabe types.

 

[RivenSkaye]

Not anymore, after very carefully illustrating the problems of yes/no fields sometimes yielding strings over ODBC. I should add this DB has been actively in use since '97, and redoing it in a much newer version of Access would probably go a long way in fixing the weirdest of the problems. But we rely on the workgroup login stuff to regulate access and permissions. And seeing as we haven't been able to find something similar with newer DB formats, it seems like we're stuck on the final version of it which was upgraded to the 2007 format...

But it seems like migrating personnel to the new Access Runtime would at least be helpful in keeping them out of the raw table data at least!

 

[The_Doc_Man]

But it seems like migrating personnel to the new Access Runtime would at least be helpful in keeping them out of the raw table data at least!

Suddenly this makes more sense. The reason that Workgroup security techniques were abandoned is that they were too easy to spoof. They were part of a library called MDAC - Microsoft Data Access Control - that was at one time as high as 5th on the SANS Institute's 20 Worst Security Threats list for Windows. Access is inherently insecure once you have gained access to the file holding the various tables.

The correct in-Access solution involves a lot of work. I had to do it when I took over a poorly designed DB built by an electronics engineer who didn't even understand normalization, much less the concept of "unity of structure" or "unity of style." The topic you would need to research to fix this would be "Securing a Database" - which involves many steps in order to keep people out of a database. However, as long as you don't have people actively seeking to break in to your data, what you can do with Access more recent than Ac2010 or Ac2013 is enough to keep the curious and the bit-twiddlers at bay.

You ARE correct that if you seriously want to secure the database in a robust way, Access as a back-end is not so solid. SQL Server, ORACLE, and several other more robust SQL engines would be better. But using MDAC methods is one of the LEAST secure approaches.