Solved Hiding Privacy Options for Untrusted Database (1 Viewer)

abdullahkhan

Member
Local time
Today, 22:28
Joined
Apr 14, 2020
Messages
231
Hello,

Is it possible to hide Privacy Options for an untrusted database? I have seen tutorials and pieces of code to hide ribbons which will also hide file menu (consequently Privacy Options) but that code is run after the database is trusted either by clicking enable content in yellow top bar or putting the database in trusted location.

But before that, anyone can close the form (which is run automatically either by autoexec macro or by selection the form in Current document options) and go to Current Document setting and enable all restricted options, than go to form design mode and remove any macro or code to prevent locking disabling of options again automatically.

Is there any way to prevent this situation other than ACCDE option?
 

arnelgp

error reading drive A:
Local time
Tomorrow, 01:28
Joined
May 7, 2009
Messages
11,130
you ask for security but still wants to use .accdb?
 

abdullahkhan

Member
Local time
Today, 22:28
Joined
Apr 14, 2020
Messages
231
you ask for security but still wants to use .accdb?
Thanks for reply. That is because I have to make some changes in DB in design mode which i do by setting allowbypass key true/false. I am not sure that will work in ACCDE that is why I want to use ACCDB.
 

strive4peace

AWF VIP
Local time
Today, 11:28
Joined
Apr 3, 2020
Messages
571
hi Abdullah ,

here are some procedures that will be helpful to you:
Rich (BB code):
'mod_NavPane_ShowHide

Sub NavPaneShow()
'200421 strive4peace
   'change MyTablename
   DoCmd.SelectObject acTable, "MyTablename", True
End Sub

Sub NavPaneHide()
'200421 strive4peace
   'change MyTablename
   DoCmd.SelectObject acTable, "MyTablename", True
   DoCmd.RunCommand acCmdWindowHide
End Sub

Sub NavPaneStartupAllow()
'200421 strive4peace
   CurrentDb.Properties("StartUpShowDBWindow") = True
End Sub

Sub NavPaneStartupDontAllow()
'200421 strive4peace
   CurrentDb.Properties("StartUpShowDBWindow") = False
End Sub

Sub AllowBypassKey_Yes()
'200426 strive4peace
   'True=Enable the SHIFT key to allow the user to
   '     bypass the startup properties and the AutoExec macro.
   CurrentDb.Properties("AllowBypassKey") = True
End Sub

Sub AllowBypassKey_No()
'200426 strive4peace
   'False=Disable the SHIFT key to prevent the user from bypassing startup
   CurrentDb.Properties("AllowBypassKey") = False
End Sub

it would be better to have just one setter procedure for database properties, but I made this easier for you ~ there are lots of other properties you can change with VBA too
 
Last edited:

strive4peace

AWF VIP
Local time
Today, 11:28
Joined
Apr 3, 2020
Messages
571
ps, Abdullah

whether or not you can press the F11 key to show the database window (Navigation Pane) is controlled by the "AllowSpecialKeys" database property. It is True or False.

To be able to launch procedures to change settings in an ACCDE, you'd need to trigger them somehow. Perhaps make a form for administrative stuff. In the Open event, prompt for a password and if it isn't right, cancel opening the form.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:28
Joined
Oct 29, 2018
Messages
13,724
Thanks for reply. That is because I have to make some changes in DB in design mode which i do by setting allowbypass key true/false. I am not sure that will work in ACCDE that is why I want to use ACCDB.
So, you should use the ACCDB, and your users should use the ACCDE. Is your database split?
 
Last edited:

arnelgp

error reading drive A:
Local time
Tomorrow, 01:28
Joined
May 7, 2009
Messages
11,130
always give the user the .accde
dont allow them to have a copy of .accdb.
only you must have possession of it.
it's that simple.
make changes using accdb, then distribute the compiled version.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:28
Joined
Oct 29, 2018
Messages
13,724
Right now it's not split but at the end it will be.
Okay, then you shouldn't have anything to worry about right now since no one else is using your database yet.
 

abdullahkhan

Member
Local time
Today, 22:28
Joined
Apr 14, 2020
Messages
231
hi Abdullah ,

here are some procedures that will be helpful to you:
Rich (BB code):
'mod_NavPane_ShowHide

Sub NavPaneShow()
'200421 strive4peace
   'change MyTablename
   DoCmd.SelectObject acTable, "MyTablename", True
End Sub

Sub NavPaneHide()
'200421 strive4peace
   'change MyTablename
   DoCmd.SelectObject acTable, "MyTablename", True
   DoCmd.RunCommand acCmdWindowHide
End Sub

Sub NavPaneStartupAllow()
'200421 strive4peace
   CurrentDb.Properties("StartUpShowDBWindow") = True
End Sub

Sub NavPaneStartupDontAllow()
'200421 strive4peace
   CurrentDb.Properties("StartUpShowDBWindow") = False
End Sub

Sub AllowBypassKey_Yes()
'200426 strive4peace
   'True=Enable the SHIFT key to allow the user to
   '     bypass the startup properties and the AutoExec macro.
   CurrentDb.Properties("AllowBypassKey") = True
End Sub

Sub AllowBypassKey_No()
'200426 strive4peace
   'False=Disable the SHIFT key to prevent the user from bypassing startup
   CurrentDb.Properties("AllowBypassKey") = False
End Sub

it would be better to have just one setter procedure for database properties, but I made this easier for you ~ there are lots of other properties you can change with VBA too
Thanks you very much for the code. Can you please tell me what is this code DoCmd.SelectObject acTable, "MyTablename", True used for because hiding NavPane is done by DoCmd.RunCommand acCmdWindowHide. Sorry if this is stupid question because I don't know much about VBA.
 

strive4peace

AWF VIP
Local time
Today, 11:28
Joined
Apr 3, 2020
Messages
571
hi Abdullah,

you're welcome

"MyTablename" needs to change to one of the table names in YOUR database ... but I don't know what your tables are called ;) ~ so you'll have to pick one you know will be there and put its name into the code where it says MyTablename

~~~
all the procedures I gave you are Subs with no parameters, which means you can click in the one you want to run, and press F5 to run it, or chose Run from the Run menu at the top.

~~~~~~~~~ Compile ~~~~~~~~~

Whenever you change code, references, or switch versions or operating environment, or modify objects with code behind them, you should always compile and save before executing any code.

from the menu in a VBE (module) window: Debug, Compile
(Alt-F11 to switch to the code window)

Fix any errors on the highlighted lines.
Add needed references, remove unnecessary references, resolve missing references
(from the menu: Tools, References...)

keep compiling until nothing happens (this is good!) -- then Save

also be sure, before compiling, to use Option Explicit at the very TOP of each module so variables that are not declared or are misspelled will be picked up by the compiler as well as many other errors than can be fixed before running.

~~~~~~~~~ Add Option Explicit ~~~~~~~~~

if the top of your module does not have a statement that says Option Explicit, then add this:
Code:
 Option Explicit  ' require variable declaration
If this was not done when the code was written, you will may need to DIM some variables -- it is best to do that anyway

> "I don't know much about VBA"

that will have to get fixed ;) you can do so much more with Access! Here is a book I started writing on programming with VBA:

Learn VBA
http://www.accessmvp.com/strive4peace/VBA.htm

VBA itself isn't difficult -- learning the object model is what takes a lot of time!
 

abdullahkhan

Member
Local time
Today, 22:28
Joined
Apr 14, 2020
Messages
231
hi Abdullah,

you're welcome

"MyTablename" needs to change to one of the table names in YOUR database ... but I don't know what your tables are called ;) ~ so you'll have to pick one you know will be there and put its name into the code where it says MyTablename

~~~
all the procedures I gave you are Subs with no parameters, which means you can click in the one you want to run, and press F5 to run it, or chose Run from the Run menu at the top.

~~~~~~~~~ Compile ~~~~~~~~~

Whenever you change code, references, or switch versions or operating environment, or modify objects with code behind them, you should always compile and save before executing any code.

from the menu in a VBE (module) window: Debug, Compile
(Alt-F11 to switch to the code window)

Fix any errors on the highlighted lines.
Add needed references, remove unnecessary references, resolve missing references
(from the menu: Tools, References...)

keep compiling until nothing happens (this is good!) -- then Save

also be sure, before compiling, to use Option Explicit at the very TOP of each module so variables that are not declared or are misspelled will be picked up by the compiler as well as many other errors than can be fixed before running.

~~~~~~~~~ Add Option Explicit ~~~~~~~~~

if the top of your module does not have a statement that says Option Explicit, then add this:
Code:
 Option Explicit  ' require variable declaration
If this was not done when the code was written, you will may need to DIM some variables -- it is best to do that anyway

> "I don't know much about VBA"

that will have to get fixed ;) you can do so much more with Access! Here is a book I started writing on programming with VBA:

Learn VBA
http://www.accessmvp.com/strive4peace/VBA.htm

VBA itself isn't difficult -- learning the object model is what takes a lot of time!
Thanks a lot for such detailed explanation. And thanks for the book link too. I'll try to learn from it as much as I can.

Best Regards
 

zeroaccess

Active member
Local time
Today, 11:28
Joined
Jan 30, 2020
Messages
631
I just moved my hide ribbon code to a public function and call it from my AutoExec macro. It used to be on the load event of my Login form - but as you say, if the DB is not trusted, the ribbon won't hide.

Now:
AutoExec runs. First step is:
RunCode: HideRibbon()

Then, it checks if trusted and proceeds as appropriate.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:28
Joined
Oct 29, 2018
Messages
13,724
I just moved my hide ribbon code to a public function and call it from my AutoExec macro. It used to be on the load event of my Login form - but as you say, if the DB is not trusted, the ribbon won't hide.

Now:
AutoExec runs. First step is:
RunCode: HideRibbon()

Then, it checks if trusted and proceeds as appropriate.
Hi. This feels like it's meant for a different thread. But yes, no code (other than Autoexec with "safe" macro actions) will run, unless the db is trusted first. Have you also tried using a custom (empty) ribbon, maybe?
 

zeroaccess

Active member
Local time
Today, 11:28
Joined
Jan 30, 2020
Messages
631
Hi. This feels like it's meant for a different thread. But yes, no code (other than Autoexec with "safe" macro actions) will run, unless the db is trusted first. Have you also tried using a custom (empty) ribbon, maybe?
Nope it's for this thread. The OP's issue was that the hide ribbon code from other discussions runs after the DB is trusted. So, the solution is you move the code to be the very first thing that happens when the DB is opened - before its trusted status is checked.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:28
Joined
Oct 29, 2018
Messages
13,724
Nope it's for this thread. The OP's issue was that the hide ribbon code from other discussions runs after the DB is trusted. So, the solution is you move the code to be the very first thing that happens when the DB is opened - before its trusted status is checked.
Understood. Then, if the db is not trusted, even with your HideRibbon() in a public function, it still doesn't hide the ribbon, right? Just checking...
 

zeroaccess

Active member
Local time
Today, 11:28
Joined
Jan 30, 2020
Messages
631
Understood. Then, if the db is not trusted, even with your HideRibbon() in a public function, it still doesn't hide the ribbon, right? Just checking...
It hides no matter what.

First line of AutoExec macro is RunCode, HideRibbon() <- public function

Second line is to check if the DB is trusted, then either load one form if trusted, or load another if not. So by the time it's checking, the DB window is already streamlined with no ribbon.

With that said, I have not yet encountered what it looks like when the yellow bar appears for an untrusted DB when there is no ribbon. It should just appear under the title bar, but I'll need to check.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:28
Joined
Oct 29, 2018
Messages
13,724
It hides no matter what.

First line of AutoExec macro is RunCode, HideRibbon() <- public function

Second line is to check if the DB is trusted, then either load one form if trusted, or load another if not. So by the time it's checking, the DB window is already streamlined with no ribbon.

With that said, I have not yet encountered what it looks like when the yellow bar appears for an untrusted DB when there is no ribbon. It should just appear under the title bar, but I'll need to check.
Hi. Sorry to disagree. Try renaming your database with a new name that you've never used before and let us know if the ribbon still hides. Thanks!

PS. Also, just to be safe, in case your folder is already trusted, try creating a new folder outside of your existing folder, and then put the new name db in there before running it. Cheers!
 

zeroaccess

Active member
Local time
Today, 11:28
Joined
Jan 30, 2020
Messages
631
Hmm, well I'm getting Macro Single Step Error 2001.

So I guess you're right.

Best policy may be to ensure the location is trusted. In my case, my .bat file copies the front end from the server to a local folder on C:, and we don't see the yellow bar. This code is really just a back up policy that gives the user some instructions on how to proceed.

In case you really need to lock it down, I would suggest giving a msgbox with instructions and exiting the application if not trusted. The user will open a blank instance of Access and go into their Options to set the trusted location.
 

Users who are viewing this thread

Top Bottom