LockNavigationPane Action Disables Linked Table Manager

[hockeygoalie29]

The title pretty much says it all. I am attempting to lock the navigation pane in order to keep users from accessing certain objects so I have an AutoExec macro that disables certain categories and then sets the LockNavigationPane action to true. However, I've noticed that as soon as the macro runs Access grays out the Linked Table Manager. I've confirmed it is the LockNavigationPane action that causes this by running just that one action in the macro and, sure enough, no Linked Table Manager.

This doens't make sense to me, and google hasn't been any help so far. Has anyone encountered this or found a way around it?

 

[boblarson]

Why do you need the linked table manager available when the nav pane is locked? It does this by the way because in the linking process you are viewing the tables that are there.

 

[hockeygoalie29]

Why do you need the linked table manager available when the nav pane is locked? It does this by the way because in the linking process you are viewing the tables that are there.

In the navigation pane, I have hidden the queries and macros to keep users from modifying them. In order to keep them from viewing hidden objects, I've locked the navigation pane. The users still need to be able to access the Linked Table Manager so that they can modify where the data is being pulled from. There are several tables that are pulled from local databases on their hard drive which are in different locations for each user.

 

[boblarson]

Just put your own button on a form and use this code in the click event:

DoCmd.RunCommand acCmdLinkedTableManager

 

[hockeygoalie29]

Just put your own button on a form and use this code in the click event:

DoCmd.RunCommand acCmdLinkedTableManager

Great suggestion. However, it looks like it still isn't allowing the linked table manager to open. Without the navigation pane locked, it works just fine. But as soon as I lock the navigation pane, the button does nothing.

This is pretty frustrating since, as far as I can tell, the two operations have nothing to do with each other.

 

[boblarson]

This is pretty frustrating since, as far as I can tell, the two operations have nothing to do with each other.

Well, as I said, they actually do in that if you have access to the linked table manager then you have access to the tables.

Not sure then how to proceed at this point then.

 

[hockeygoalie29]

Well, as I said, they actually do in that if you have access to the linked table manager then you have access to the tables.

Not sure then how to proceed at this point then.

Very true, but don't I have access to the tables from the navigation pane anyway even if it is locked?

EDIT: The only thing that I know of that you can't do to a table with the navigation pane locked that you can do with it unlocked is to delete the table. But then again, you can't delete a table using the navigation pane anyway. So unless I'm just not understanding or I'm overlooking something, I don't see how disabling the linked table manager when the navigation pane is locked helps protect your tables.

 

[boblarson]

Very true, but don't I have access to the tables from the navigation pane anyway even if it is locked?

What do you mean "LOCKED?" How are you supposedly "locking" the nav pane. You can make it so it doesn't display, but you can't lock anything (as far as I've ever seen).

 

[hockeygoalie29]

What do you mean "LOCKED?" How are you supposedly "locking" the nav pane. You can make it so it doesn't display, but you can't lock anything (as far as I've ever seen).

In my AutoExec macro I'm running the "LockNavigationPane" action with an argument of "Yes". I'm not trying to keep the navigation pane from displaying, rather, I'm trying to keep the user from editing the view. So by locking the navigation pane, the user can't change the navigation options such as "Show Hidden Objects."

The end game is that I do not want users editing queries or macros so I am removing them from view. But all a user has to do is check show hidden objects and they have instant access to them. So by locking the navigation pane, they can't get around my "security."

 

[boblarson]

they can't get around my "security."

Well, it would look like you are in a Catch 22 situation. You can't lock it and have the linked table manager and you can't unlock it because someone might get in. You'll have to figure out what is the more important of the two.

Personally, I never let anyone into the nav pane or database window anyway, so I just set it to not display and then disable the F11 key by setting the Use Access Special Keys checkbox to unchecked.

 

[hockeygoalie29]

Well, it would look like you are in a Catch 22 situation.

Yeah, this is what I figured. If there was a way to make queries and macros read only, I wouldn't have an issue. The forms, reports, and code are easily handled by creating an ACCDE, but as far as I know there is no way to do the same with queries and macros.

Personally, I never let anyone into the nav pane or database window anyway, so I just set it to not display and then disable the F11 key by setting the Use Access Special Keys checkbox to unchecked.

That was my first thought, setting up a switchboard and disabling the navigation pane. But as far as I know you can't open up a table from a switchboard can you?

 

[boblarson]

Yeah, this is what I figured. If there was a way to make queries and macros read only, I wouldn't have an issue. The forms, reports, and code are easily handled by creating an ACCDE, but as far as I know there is no way to do the same with queries and macros.

Compiling SHOULD not let users edit macros (but I don't know about 2007- in 2003 and prior it does do this so they can't get in, but in the new realm some macros may still be editable - I'd have to test).

That was my first thought, setting up a switchboard and disabling the navigation pane. But as far as I know you can't open up a table from a switchboard can you?

Don't know about the built-in switchboard but you can in your own if you use

DoCmd.OpenTable "Table Name Here"

But I never let users directly use tables either because you lose all control once you let them do that. I use a form that LOOKS like a table (in datasheet view) but it has the events so you can use the before update event to validate, make certain things read-only, etc.