I need help publishing/deploying an ACCESS 2013 applicaiton

Posted on 2014-12-26
Last Modified: 2014-12-28
Hi Experts,
I have an Access 2013 application that I want to deploy.  Is there a way for me to prevent users from accessing the tables or the VBA code?  How can I deploy my application so that the user's interaction with the application is only through the front end/user interface?

Thanks in advance,
Question by:mainrotor
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Accepted Solution

Robert Sherman earned 167 total points
ID: 40519259
If you absolutely want to keep anyone from getting at the code and/or design modes, you can save the database as an executable only file.  This will compile all of the code and create a new version of the database file with an .accde extension.   In the .accde file, you can not get into any of your object's design modes and can not view any of the VBA code.   BE AWARE that nobody can, including you.  SO KEEP THE ORIGINAL accdb file for yourself, as that is the only way you will be able to update the database objects.. if you ever make changes, you then would just create a new .accde file to distribute to your users.

To do this, you go into the File menu / backstage view, and select "Save & Publish".  From there you should see a "Make ACCDE" option.

You should thoroughly test your application to make sure it doesn't have any errors, and it is recommended to have error handling code throughout your application because if the executable database encounters any code errors it will not be able to display useful info about the error and won't go into debug mode.  So, the idea is to have user-friendly error messages for any potential errors in order to make troubleshooting client issues easier.

Hope that helps!

EDIT:  Because it bears saying a second time, KEEP THE ORIGINAL FILE!  You WON'T be able to make any changes to the .accde file.
LVL 85

Assisted Solution

by:Scott McDaniel (Microsoft Access MVP - EE MVE )
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 167 total points
ID: 40519539
Just a note - in 2013, the method to create the .accde format is under the "Save As" menu item. You click the File menu, then Save As, and you can then save the file in the .accde format.

However, even with the .accde format users can still create, view and modify Tables and Queries. You can hide those to some degree by removing the navigation pane from that file. If you do that, you'll have to have a menu form to allow the user to navigate your application. You should also disable the ShiftKeyBypass (, along with a few other things. These MSFT articles should give you some ideas. These are for 2007, but the same concepts apply:

Regarding data security: you really can't keep someone from mucking around in your Tables and Queries. A modestly inquisitive user will quickly find they can link to your database from another one, and import all of your tables and queries. If you want real data security, move the tables and queries to SQL Server, and secure them there.
LVL 38

Assisted Solution

PatHartman earned 166 total points
ID: 40519964
you can save the database as an executable only file
There is no such animal as an executable Access file.  The best you can do is partially complied which is what the .accde is.  That step removes all the source code and leaves only the p-code which renders the forms/reports/modules unavailable in design view.  An executable file is quite different and due to its current structure with all objects residing in a database container, Access will never be executable in the technical sense of the word.

In an .accde, the user can also muck around with macros if you used them.  As Scott mentioned, SQL Server is the best place for data but you can't just move the queries.  That is a huge change to the app.  There is also nothing you can do about macros if you used them.  The only solution would be converting them to VBA so they could be hidden.

I take a couple of other steps after compiling the app.  These steps won't deter someone with experience but they can thwart the average user.
1. Hide all the objects
2. Rename the app as .accdr.  This tells Access to pretend to be the runtime engine so even if the users have the full version of Access installed, Access will pretend to be the runtime engine when it opens the app so it will not allow access to ANYTHING in design view.  This is also easily thwarted if you understand what was done.

Author Closing Comment

ID: 40521343
Thank you all very much.  The help you all provide is EXCELLENT!


Featured Post

Enroll in July's Course of the Month

July's Course of the Month is now available! Enroll to learn HTML5 and prepare for certification. It's free for Premium Members, Team Accounts, and Qualified Experts.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Your data is at risk. Probably more today that at any other time in history. There are simply more people with more access to the Web with bad intentions.
In this blog post, we’ll look at how ClickHouse performs in a general analytical workload using the star schema benchmark test.
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question