Read design/read data problem

[FishMan]

Hi
I have a DB set up with admin, read only and full data users. The DB is
not split, but on a central server which is accessed via a shortcut
created in the security wizard. Everything seems to be OK, except that
full data users are still allowed to view the design. When I go into
'User and group permissions' and list by groups, the full data
users have the 'view design' box checked. If I try to uncheck this
box, the check marks in the read/update/insert/delete boxes uncheck at
the same time! I do not want any of the full data users to even see the
design, but do want them to be able to read etc.

Seems strange to me that the full data users can even see the design,
and stranger that I cannot turn this off without removing all their
other permissions.

Any help gratefully received. (NB DB cannot be split, don't ask)

[Joan Wild]

That's the way it is. In order for users to read data, they need permission
to read design.

An alternative is to deny all permissions on the tables, and use RWOP
queries for all data access. RWOP means run with owner permissions. It
allows users to access the tables as though the query owner was running the
query. They won't be able to open tables directly, nor read their design.
You just grant the necessary permissions on the query.

They shouldn't be able to get to the database window, though. You need to

Create custom menus/toolbars for use throughout your application.
Create a startup form (a main menu form if you have one) that is opened on
startup.
Use the features in Tools, Startup to
set the startup form
set your default menu (the custom one you made)
disable all the checkboxes about allowing built in menus, toolbars,
changes etc.
hide the db window (ensure the custom menu you create does not
include the Windows, Unhide item)
Click on the Advanced button and uncheck the allow special keys
(this will disable the F11 key, among others)

If you need to bypass these startup features, you can hold the shift key
down while you open the db. If you feel that your users may use this to
bypass your settings, you can disable the shift key bypass - there's an
example in help for doing this(look for AllowBypassKey) or at
http://www.mvps.org/access/modules/mdl0011.htm
and
http://www.mvps.org/access/general/gen0040.htm

You can also create a MDE from your database, which will prevent changes to
forms, reports and modules (If you do this, be certain to keep your original
mdb in case you need to make changes).

--
Joan Wild
Microsoft Access MVP

[FishMan]

Thanks Joan, seems like that will achieve what I want.

Bit strange though, limiting the choice of permissioins like that. Why
was it decided that all data users HAD to be able to see the design? I
don't want them to, and a simple check box would seem like the best way
to stop them. Confused!

[TC]

It's quite a common requirement, even in industrial strength databases,
that you can't read data from a table, unless you can see the design of
that table.

I guess the thinking is this. If the database manager is going to give
you data from the table, it must certainly give you the field types.
(For example, you need to know whether a value 999999 is a numeric
value, or is actually a string value which happens to be all-digits in
this particular record.) And there are arguments for saying that it
should also give you the field names. And you can tell certain other
characteristics of the fields, by yourself. (For example, you can tell
whether a field is nullable, by trying to store a null in it. You can
tell whether it allows duplicates, by trying to store a duplicate
value, & so on.)

So, at the end of the day, if the database manager is going to give you
the /data/, plus the field types & names, & you can find out all those
other things yourself, then: voila! You are now in possesion of most of
the detailed design of the table.

IOW, I believe it doesn't make sense to say, "give me the data from
table X, but do not let me see, or determine, the detailed design of
that table".

HTH,
TC