Preventing seeing the names of MS Access objects (and importing them) from other databases (using External Data/Import), or whatever...

How do you prevent MS Access database objects (tables, modules, forms, macros, reports and queries) from being visible from other databases using "External Data/Import" (or any other way, from any other database, or whatever...), EXCEPT from the ones that are allowed (e.g. the front-end database that originated from the split operation that also produced the back-end that I am trying to hide objects of)?

My problem is this: even though my back-end database is password-protected, my front-end isn't and I don't want it to. However, the front-end is secured in every other possible way (shift key disabled, converted to .accde, special-keys disabled, ribbon disabled, etc.).

HOWEVER, someone simply has to create another Access database and do External Data/Import on my front-end to be able to see all its objects, including the back-end tables that it links to, event though every object in it has its "Hidden" property checked True, and therefore bypass all my so called "protections".

Notice also that my restriction needs extend not only to other Access databases, but to (reasonably) ANY other application.

I hope you can help on this very important matter to me.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I hide the objects.  If they can't see them, they are less likely to mess with them.  This hides them from the import as well.  You would need to open the .accde and get access to the navigation pane to unhide them.  

Nothing in Access is truly secure.  If you are worried about security, you need a compiled language.
J2015Author Commented:
Please read my post : "All my objects have their Hidden property set to True", and like I said, it does not make any difference. Anybody can create a new blank database and from it they will be able to connect to the front-end and see all objects in it, whether they are hidden or not, and whether the objects belong to the front-end or whether they are linked tables that belong to the back-end.

What I need is some sort of "Linkable=False" database property for my front-end. Do you know if such a database property exist? By the way, I am using Access 2007.
Sorry, I should have included more detail.  To make the objects hidden to the outside world, you must set the ShowHiddenObjects property to false.  If you leave that box checked, the objects show up in the list greyed out.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

J2015Author Commented:
Can you please explain in details how I can set this property. Is it in the Access options?
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"database objects (tables, modules, forms, macros, reports and queries) "

"to be able to see all its objects" ... ".accde"

If you have an ACCDE, then you may be able to 'see' the objects in bold above from an external db, but you will not be able to import (export) those objects from an ACCDE,  Unfortunately, the Tables & Queries are a different story.

J2015Author Commented:
Thank you. I now understand what you mean. The objects' Hidden property has to be set to True AND the Show Hidden Objects checkbox under Navigation Options needs to be checked ALSO.
Yes, it's a 2-pronged approach.  Otherwise, you wouldn't have any way to unhide them to work on them.

My preference would be for MS to create a "distributable" that is completely locked down but I won't hold my breath since they have gone down the rabbit hole chasing the web and will not do anything to support desktop apps.  someone ate the breadcrumbs and so they have no way back.  We're on our own.
J2015Author Commented:
Thanks Pat. By the way I failed to mention earlier that the front-end is an .mdb file (file A) and that I was connecting to it using an Access 2007 database (file B) from within an Access 2007 application. Whether I set the Show Hidden Files navigation option to false in Access 2007 before closing file A makes no difference. I can see all the objects of file A from file B if I turn the navigation option setting back on, including the linked tables that file A has, which belong to my back-end (file C). I absolutely must prevent this, since malevolent people could get to the back-end data this way and fool around with it. The only way that I found to improve the situation a bit is to convert file A to .accde. People would still be able to see the tables of file A (.accde) from file B, but not not its linked tables pointing to file C. At least the back-end data is a little bit safer this way. Being able to see file A's local tables from file B is not catastrophic. They just contain tidbits of data used for sandbox operations.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"shift key disabled"
Don't fool yourself here.

Anyone ... from an external db can re-enable the Shift Key Bypass property (several free tools to do so) and pretty much any other property. Once that happens, your db is essentially wide open again from a table (linked or otherwise) and query standpoint. Consequently, someone can get to data in a linked db.

There is virtually  no way to completely secure linked tables in the FE, ever since ULS was removed in 2007.

j2015, If you are really concerned about the data, you need to get it out of Jet/ACE and into SQL Server or some other database that can actually be secured.  Even with ULS, Access security would only stop a novice.  No file based database can ever be secure since anyone can copy the BE to a thumb drive and leave the building with it.  Then they can fiddle with it as they like.

One other option I have seen employed involves Active Directory.  I can't tell you exactly how to implement it but your support person should be able to work it out.

Put the BE in a directory that is completely hidden so no one can actually "see" it by normal navigation methods.  They would have to know the directory name.  You can link to some "safe" copy of the BE which people can find and then at start up, switch to link to the hidden BE.  Then switch back during shut down.  That way, unless they think to attempt to import while the FE is open, they will only see links to the "safe" copy.  So, unless people actually analyze the data, they won't even know they are looking at something sanitized.  It's a diversion that will let them think they have succeeded when they actually haven't.  And don't forget, mucking around with the company's data is not only a firing offence, it is prosecutable.
J2015Author Commented:
I understand all of your wise comments about the fragility of Access files and totally agree with everything you all say. However, the system I developed had to be made in Access. No other way around it. That's what my customer wanted, needed, and could only afford. Period. But, this being said, I wanted to make it as safe as possible, within the limits of Access, and thanks to this exchange I was able to take care of the only remaining crack through which a "normal" person could damage the system.

Thanks everybody, and feel free to continue commenting!
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Just noting my comment:

"shift key disabled"
Don't fool yourself here.
had to be made in Access
Are you confusing Access the RAD development tool with Jet/ACE the database engines?  

Access can link to any RDBMS that supports ODBC and SQL Server Express is FREE.  It is limited in size but otherwise fully functional.
J2015Author Commented:
No, I'm not confusing anything.

It's a long and complicated story, but believe me it had to be done in Access, the RAD tool & DB engine. I know all about ODBC and SQL Server Express. If it was me who made the decisions, at least the back-end would have been SQL Server. It's just that the customer (a very small division of the Ministry of Health) does not have the right to install anything. Everything has to be approved from "above". Getting the approval and the budget to get the application developed by their IT department would have taken forever and would have cost 10 times what I'm charging them. So they had to go with what they have. Access solves their problem, Everybody's happy. End of the story.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.