User Groups and Permissions Disabled No Matter What....

[skyscraperfx]

Anyone know why in Access 2010/2016 the Administer group permissions level functions are disabled no matter if it is Admin logged in with full permissions, and eevry other test user too, yet I cannot get the full Permissions buttons to enable?

Also as being "Run as Administrator"; nothing seems to get full permissions in a .accdb format db.

[orange]

see this for more info found via Google

For most people, Access User Security no longer exists as it was in 2003.

Here's a note from StackOverflow

[skyscraperfx]

I have done the basic google questions and know there has been a change to a new security model for Access (2010 chnage is what I am referring to) not a "no security" situation but an updated method; but what may be causing this in the new Access security model under the new security model when every admin and user has full permissions and user group permissions including the app installing admin?

Thanks for your help.

Even this full description has not provided any solution to this unique situation:

Introduction to Access 2010 security


https://support.office.com/en-us/art...f-68d9f186d6ca

I CANNOT get this functionality in Access 2010 or 2016:

https://public-bn1305.files.1drv.com...drts=162450470

[NTC]

fundamentally the security feature set was discontinued/deprecated beyond 2003. The links Orange provide tell you that as long as you open in .mdb/mde file format they continue to operate at least through the 2010 edition (that was the vintage of the info on the link provided).

I honestly don't know if they continue to work in the 2013, 2016 editions at all. Fundamentally you should drop them is my advice - rather than struggle to prolong them. Open/create a brand new database in your current edition using the .accdb (default) file type.... then import all the objects of your old database.

[orange]

I agree with NTC. He said it much better than I could. That is the essence of posts related to User Security today.

[skyscraperfx]

fundamentally the security feature set was discontinued/deprecated beyond 2003. The links Orange provide tell you that as long as you open in .mdb/mde file format they continue to operate at least through the 2010 edition (that was the vintage of the info on the link provided).

I honestly don't know if they continue to work in the 2013, 2016 editions at all. Fundamentally you should drop them is my advice - rather than struggle to prolong them. Open/create a brand new database in your current edition using the .accdb (default) file type.... then import all the objects of your old database.

Now I understand. BUT, in old Access security you could control table level security simply. Now I cannot even find detailed security, now it seems to have to be handled in code and tracked by the admin and the "Trusted Location" is as "detailed" as it gets. I just want to find an easier solution. Unless I am still missing something in Access 2010.

[skyscraperfx]

fundamentally the security feature set was discontinued/deprecated beyond 2003. The links Orange provide tell you that as long as you open in .mdb/mde file format they continue to operate at least through the 2010 edition (that was the vintage of the info on the link provided).

I honestly don't know if they continue to work in the 2013, 2016 editions at all. Fundamentally you should drop them is my advice - rather than struggle to prolong them. Open/create a brand new database in your current edition using the .accdb (default) file type.... then import all the objects of your old database.

I'll have to do this which is fine. But now how would an admin handle table by table security as tracked by Access rather than me coding and tracking it myself?

[NTC]

There are good reasons the old security design was discontinued. Today a developer must implement whatever security is appropriate to the user base. In general removing the F11 capability (to the Navigation Pane), distributing an .accde file time (cannot go into design view) and password protecting the file itself are the 3 core security elements to be implemented if thought necessary. It should be understood that this is secure for the level of the average un-motivated, opportunistic or non technical users. If there is a motivated, technically adept serious hacking concern - another technology should be used for your application.

Anything inside the user interface, such as limiting users to viewing/editing specific records, requires developing a log-in screen to obtain user identification and then designing object behavior and record set queries with that information.

[skyscraperfx]

There are good reasons the old security design was discontinued. Today a developer must implement whatever security is appropriate to the user base. In general removing the F11 capability (to the Navigation Pane), distributing an .accde file time (cannot go into design view) and password protecting the file itself are the 3 core security elements to be implemented if thought necessary. It should be understood that this is secure for the level of the average un-motivated, opportunistic or non technical users. If there is a motivated, technically adept serious hacking concern - another technology should be used for your application.

Anything inside the user interface, such as limiting users to viewing/editing specific records, requires developing a log-in screen to obtain user identification and then designing object behavior and record set queries with that information.

Thanks. Do you have any thoughts on Access web app and a Sharepoint back end? The future goal seems to be easier team access to company marketing and sales information with some input capability already in a Desktop Access db but from the web it could be more easily team accessed is the theory.

[NTC]

Access web app / SharePoint (or 365 Account) is primarily directed for intra-organizational applications. It helps if the organization is already SharePoint platformed as SharePoint itself is somewhat of a large application to administer.

It should not be considered for a public facing web application. Instead one should use Microsoft's premier web development environment ASP .NET

There is no port. It is a total rewrite. Because it does not have VBA coding nor is tightly coupled with the local OS - a very feature rich Windows Access application is difficult to impossible to replicate as an Access Web Application. But many intra-organization requirements are very viable. One must accept the feature set as is available.

[skyscraperfx]

Access web app / SharePoint (or 365 Account) is primarily directed for intra-organizational applications. It helps if the organization is already SharePoint platformed as SharePoint itself is somewhat of a large application to administer.

It should not be considered for a public facing web application. Instead one should use Microsoft's premier web development environment ASP .NET

There is no port. It is a total rewrite. Because it does not have VBA coding nor is tightly coupled with the local OS - a very feature rich Windows Access application is difficult to impossible to replicate as an Access Web Application. But many intra-organization requirements are very viable. One must accept the feature set as is available.

Thanks. Yes this is for most organizational use. It looks like there main current Access db can stay, but a parallel test version can be designed to use Sharepoint lists for its back end which can be fed as needed from the desktop Access back end. And org access to that SP hosted data can be from Access desktop located forms, the Access web app forms have some limitations as far as things like VBA and apparently a number of tools can be tried. InfoPath or SP Designer or VS.NET org utilized front ends can be tested, and now they can rethink the way they have organized there current "all in one" main Access db, because now they can separate out some basic input and read stuff out of the Access desktop app they use all the time at this time.

I stated all that in case someone else is facing a similar problem. (That there is hope! LOL)

Do you have any opinion on InfoPath? And this is mostly intra-organizational uses. Anything they need public facing can just be done in as you say ASP.NET but that seems minimal they just mine some easy input public leads from their web which they are also rethinking and now it makes sense to pitch the idea of staying in the same MS realm of platforms. But with Visual Studio any other dev environments can still be access just in case.

Have you any opinion about Sharepoint Designer?

Thanks for your help.