You can also prevent folks from "jumping out" of the app.

There are a few tricks which could make it tough for someone to get to the linked tables, some documented, some not, to include:

- not showing the DB window so they can't get to the tables,

- creating "pass through" queries as the linked tables, which are by nature read-only. Updates would be done via code calling stored procedures using a service account.

- "hiding" the tables in a reference DB acting as a "forms library", which can be linked in via a startup module. The forms library can be compiled into an MDE file, so any user "breaking in would see NO "offically developed" objects other than a module which has been compiled and not readable.

1) and 3) are least invasive, but really are just designed to slow a user down (they don't really "fix" the problem, since the user still has direct access to the tables). If you were to implement access security you oculd actually make it fairly painful to "break in", but still as Steve mentioned - you would still need to have those "admin sanctions" in place (i.e. not only is it painful to break in to the app, but if I am caught doing it - I will get counselled and/or fired), as well as removing direct user privs and setting up some form of a service account.