A note of caution.
It is quite difficult to secure the data in a pure Access solution from a dedicated hacker or a disgruntled employee bent on destruction. Usually the security of data from non-users is accomplished using Windows filesystem permissions and/or networking permissions. Fence off the LAN from the world, then that's done.
But if it's the employees we are protecting from, then I would argue we have a bigger problem and it's not a IT problem but rather a human resource problem. For most parts, employees already have incentive to be honest and not break the application- after all, their paycheck depends on it.
It must be understood that even with a secured application, it still can be:
1) cracked with a password cracker available for download, even for ULS
2) read plaintext in a notepad or any text editor
3) once the access is granted, whether directly or indirectly, they may find a means of copying the data off.
With all that in mind, my usual recommended guide for ULS security is Jack MacDonald's
pdf.
Reading the pdf will help make sense of below and how you how to actually do it.
IMHO, a best solution I would use would be to create at least two separate mdws, one that contains the administrative privileges, the other that is distributed to users. The first one is never distributed so that means the application get distributed with the administrator user "missing". It is difficult to crack the .mdw when there's no info in it to be cracked other what they already were privileged with but is not bulletproof as it is possible to crack the .mdb file and extract the SID and reconstruct the missing user. Hopefully, that expertise would be beyond most of the users anyway.
You also definitely want to compile the .mdb into a .mde as it makes it difficult to do any design changes or even just reading the source code. If you have dough to burn, you could also buy MDE Code stripper from EverythingAccess.com for extra precaution (I have not used that product neither can I comment on its effectiveness. Caveat Emptor.) If the ULS is properly set up, the user will not have any permissions to the tables and queries and lack the permission to create new tables/queries so import/export would be no-go. The only permissions the users should have is forms and only through the forms can they execute queries/open & print reports and access the table. I can't recall if forms is able to execute other objects that the user do not have the permissions, but if that is the case; that means certain queries that will be used by forms & reports will have to be written with WITH OWNERACCESS OPTION, so the query can be owned by someone else without giving the users permissions to the base tables or queries this query is based upon.
Hopefully that helps.
