Hiding Tables in MDE file

[J. Joshi]

Is there any way to completely hide the table (linked or
importaed) to an MDE file. I just dont want to hide the
tables using the HIDE feature as some of our users are
quite sophisticated. And maintaining permission sis a
nightmare when the user-group grows. I want to be able to
create an MDE file without access to queries or tables.

Joshi

 

[Rick Brandt]

Is there any way to completely hide the table (linked or
importaed) to an MDE file. I just dont want to hide the
tables using the HIDE feature as some of our users are
quite sophisticated. And maintaining permission sis a
nightmare when the user-group grows. I want to be able to
create an MDE file without access to queries or tables.

Depends on your definition of "quite sophisticated" users. Without using
User-Level security all you are doing is obscuring, not securing. You
could for example have no linked tables in your distributed file and have
code that creates the links in Runtime as required and then deletes them
when no longer in use. This would likely be fairly slow and might cause a
lot of bloat in your file. If a user killed his PC while the app was
running though he would still be able to open your file and see some of the
links that never got deleted.

You can prefix all of the table names with USYS and Access will treat them
as system objects instead of merely hidden ones. Granted your users can
turn on the option to view system objects just as easily as hidden ones,
but fewer of them might think to do that.

Ultimately you are using a file-based system and users who have access to
the file for *use* will also have enough access for *misuse*. When that
becomes a big enough concern then you really should be looking at a
server-based engine with real security features.

 

[Albert D. Kallal]

It is not 100% clear why you mean by hide.

However, you an certainly complete hide the ms-access interface from your
users.

You don't need code, nor do you need security.

Try downloading the 3 example of a sample application here:

http://www.attcanada.net/~kallal.msn/msaccess/DownLoad.htm

That above appellation has all of the ms-access interface hidden..and did
not requite security, or code.

And maintaining permission sis a
nightmare when the user-group grows.

The above is not true at all. If you implement security correctly and ONLY
assign users to groups..then security is a snap. You can read what I do to
make security easy..but the real security is to only assign users to
groups,a nd assign forms etc to groups. Doing this means the NO USER
security exists in the database....but ONLY in the workgroup file. If you do
start assigning users to actual application objects like forms/reports
etc..then I do agree that security is nightmare..but only because of the
wrong approach...not that security is difficult.
Anyway..give my that sample download a try...and, that article on how I make
security easy is here:

http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

 

[david epsom dot com dot au]

You can create applications where

(a) the forms and reports are bound to tables or
queries in a different database;

and/or
(b) the code refers to queries or tables in a
different database;

and/or
(c) queries refer to queries or tables in a different
database.


If you do this, the 'linked table manager' is of no
benefit: you have to manage your data location in code.


When creating a select query, the format can be like this:

SELECT * FROM [database full path].[table name];

You don't need to save a query like that: you can
bind a form or report to a query like that.

Using techniques like this, you do not need any linked
tables at all.

(david)