Can an Access query be protected from being changed/deleted?
Hi,
I want to protect my query so that changes can't be made. Can the query be changed to read only or protected?
I want to protect my query so that changes can't be made. Can the query be changed to read only or protected?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can no longer be changed to read-only or protected.
That's not an option in A2003+.
How far back was it an option?
That's not an option in A2003+.
How far back was it an option?
JET 4.0, so A2003 and back. ULS (User Level Security) can restrict design permissions on a query and also apply "Run with owner permissions" so anyone can still execute it, but not modify it in anyway.
But with ULS gone in ACE (and it's really not, but that's another discussion), it's no longer an option.
Jim.
But with ULS gone in ACE (and it's really not, but that's another discussion), it's no longer an option.
Jim.
But with ULS gone in ACE (and it's really not, but that's another discussion), it's no longer an option.
https://support.office.com/en-us/article/What-happened-to-user-level-security-dcb633f8-70c1-45d3-a373-2f3eafa904a5
and
https://support.office.com/en-us/article/Set-or-change-Access-2003-user-level-security-in-Access-2010-0c6a10e7-966f-44f4-864e-5d2ef79439fa
Interesting.
A reason to stick with .MDB, rather than a lack of reasons to switch
Not that I have seen any good reason to switch to an accdb, since the only things that those file types support are things you shouldn't be using anyway (attachment fields, multi-valued fields and other non-SQL Server compatible abominations) and so there's no operational need or performance benefit to be gained by the switch..
but that's another discussion
:0
https://support.office.com/en-us/article/What-happened-to-user-level-security-dcb633f8-70c1-45d3-a373-2f3eafa904a5
and
https://support.office.com/en-us/article/Set-or-change-Access-2003-user-level-security-in-Access-2010-0c6a10e7-966f-44f4-864e-5d2ef79439fa
Interesting.
A reason to stick with .MDB, rather than a lack of reasons to switch
Not that I have seen any good reason to switch to an accdb, since the only things that those file types support are things you shouldn't be using anyway (attachment fields, multi-valued fields and other non-SQL Server compatible abominations) and so there's no operational need or performance benefit to be gained by the switch..
but that's another discussion
:0
OK, since you brought it up<g>, on the links you posted, it's important to understand that as was in the past, ULS is still there and always on.
Even with an ACE DB, there's still a work group file and ACE/JET still logs in with a username of 'admin' and a blank password.
What Microsoft did when they "stripped it out" is simply removed all the ACL's (Access Control Lists) on objects from the DB.
What I've never confirmed is:
1. If they reset those just on converting to a .accdb, or if they remove them on every compact and repair.
2. If you can still set security attributes through DAO.
My guess is that they didn't cut much off and you can still set the attributes, but I would suspect that they might drop the ACL's on every compact and repair.
Jim.
Even with an ACE DB, there's still a work group file and ACE/JET still logs in with a username of 'admin' and a blank password.
What Microsoft did when they "stripped it out" is simply removed all the ACL's (Access Control Lists) on objects from the DB.
What I've never confirmed is:
1. If they reset those just on converting to a .accdb, or if they remove them on every compact and repair.
2. If you can still set security attributes through DAO.
My guess is that they didn't cut much off and you can still set the attributes, but I would suspect that they might drop the ACL's on every compact and repair.
Jim.
Nick's idea is a good one, because you can protect the VBA project code.
Jim.