What Is an ACCDE File? Compiled Access Database Explained

An ACCDE file is a compiled Microsoft Access database — the deployment format developers hand to end users when the ACCDB source must stay locked. If someone sent you a database that opens and runs but Design View is greyed out, you are looking at an ACCDE file, not a broken ACCDB. Access saves all VBA code in compiled bytecode that cannot be viewed or edited, which protects intellectual property and prevents accidental form changes on production front-ends. IT admins encounter ACCDE files during Access database deployment to branch offices, client deliverables, and Access Runtime rollouts where full Access licenses are unnecessary. This guide explains ACCDE vs ACCDB differences, what Make ACCDE locks, how to create an ACCDE file step by step, and the limitations you must plan for before deleting your source ACCDB.

The ACCDB file is the editable source database — forms, reports, VBA modules, and macros open in Design View. The ACCDE file is the compiled Access database output: same runtime behavior, no design access. Use ACCDB during development; distribute ACCDE to users who should run the app but not alter it.

• File extensionACCDB = source (.accdb). ACCDE = compiled deployment (.accde).
• Design ViewACCDB: full Design View on all objects. ACCDE: Design View disabled for forms, reports, modules, and macros.
• VBA source codeACCDB: VBA editable in the IDE (Alt+F11). ACCDE: source removed; only compiled code runs — VBA source code protection for your IP.
• Data and queriesBoth run queries and accept data entry through forms. Linked back-end tables in split-database setups behave the same in ACCDE front-ends.
• Typical useACCDB: developer workstation. ACCDE: end users, clients, Access Runtime distribution, multi-user front-end copies on each PC.

Running Database Tools, Make ACCDE compiles the current ACCDB into a new ACCDE file. Access removes human-readable VBA from modules and class modules, compiles remaining code to bytecode, and locks structural design on forms, reports, macros, and navigation objects. Tables, queries, and data remain functional — users filter, append, and update records through your forms as before.

What you lose in the ACCDE: ability to edit control layouts, change event procedures, add new queries in Design View on locked objects, or export module source. What you keep: full runtime execution, linked table connectivity to a shared back-end ACCDB, and report printing. Developers who skip retaining the ACCDB discover too late that a client-requested label change requires the source file — not the compiled ACCDE alone.

Start from a working ACCDB — Make ACCDE is unavailable on files already saved as ACCDE. Open the front-end ACCDB in full Microsoft Access (2016, 2019, 2021, or Microsoft 365), fix compile errors in VBA (Debug, Compile), then follow these steps:

1. Open the ACCDB front-end in AccessUse the split-database front-end file, not the back-end table ACCDB, unless tables live in the same file you intend to compile.
2. Compile VBA without errorsPress Alt+F11, choose Debug, Compile [Project Name]. Make ACCDE fails or produces broken output when compile errors remain.
3. Click Database Tools, Make ACCDEOn the Database Tools tab, click Make ACCDE in the Database Tools group. Choose a save path and filename — Access creates a parallel .accde file without overwriting the ACCDB.
4. Match 32-bit or 64-bit OfficeCompile on the same bitness users run. Access Runtime deployments must match the ACCDE bitness installed on target workstations.
5. Test the ACCDE before distributionOpen the ACCDE on a non-developer machine or Access Runtime install. Confirm forms, reports, and linked tables work without Trusted Location warnings blocking macros.

For VBA patterns that must compile cleanly before Make ACCDE, review our MS Access VBA guide. For split-database deployment, see multi-user Access database setup practices.

• Protect VBA intellectual propertyClients and competitors cannot read your module source from a distributed ACCDE — only compiled bytecode executes.
• Prevent accidental design changesEnd users cannot resize forms, delete controls, or break validation rules in Design View because it is unavailable.
• Standard Access Runtime deploymentShip ACCDE front-ends to users with free Access Runtime instead of full Office licenses — common for US small business rollouts.
• Controlled version distributionDeploy one tested ACCDE build to fifty workstations; replace the file when you publish a new compiled version from the master ACCDB.
• Reduce support tickets from tamperingWhen help desk calls trace to user-edited forms, ACCDE deployment eliminates unauthorized layout changes at the source.

ACCDE files trade flexibility for protection. Plan for these constraints before converting your only copy of a production database.

• No design-time editsEvery form tweak, new report, or VBA fix requires opening the source ACCDB, making changes, recompiling, and redeploying a new ACCDE.
• Irreversible conversionYou cannot recover VBA source from ACCDE if the ACCDB is lost. Maintain secure backups and version history of the ACCDB master file.
• Version and bitness lock-inACCDE files compiled in Access 365 may not open in older Access versions. Test compatibility before sending to clients on legacy Office installs.
• Security is not encryptionACCDE obscures VBA but does not encrypt data. Pair deployment with network permissions and guidance on securing Access databases for sensitive records.

Role-based permissions on linked back-end files still matter — read more on permissions in MS Access when deploying compiled front-ends to shared networks.

• Can you convert an ACCDE file back to ACCDB?No. The Make ACCDE process strips editable VBA source and design-time objects into a compiled format. There is no supported reverse conversion. Always retain the original ACCDB in secure version control or backup storage before distributing the ACCDE file.
• Can I edit forms or reports in an ACCDE file?No. Design View is disabled for forms, reports, macros, and modules in an ACCDE file. Users can run the application, enter data, and execute queries, but cannot change layout, VBA logic, or object structure without the original ACCDB.
• What happens if I lose the original ACCDB and only have the ACCDE?You cannot recover VBA source code or form design from the ACCDE alone. You would need a backup ACCDB or rebuild the application from scratch. Treat the ACCDB as the master source file and the ACCDE as a read-only deployment copy.
• Does an ACCDE file work with Microsoft Access Runtime?Yes. ACCDE files are the standard format for Access Runtime deployment — end users run your compiled front-end without a full Access license. The back-end ACCDB with tables can remain separate in split-database setups while each user receives an ACCDE front-end.
• Do 32-bit and 64-bit ACCDE files work interchangeably?No. Compile the ACCDE with the same Office bitness your users run. A 32-bit ACCDE fails on 64-bit Access installs and vice versa. Match ACE driver bitness when linking ODBC sources inside the compiled database.
• Can users still edit data in tables inside an ACCDE?If the ACCDE includes linked tables to a shared back-end ACCDB, users edit data through forms bound to those tables — data changes persist normally. If tables are embedded inside the ACCDE itself, data entry still works, but schema changes require the original ACCDB.

An ACCDE file is the compiled Access database format for secure deployment — same runtime, locked design, protected VBA. Keep your ACCDB as the editable master, use Make ACCDE for distribution, match Office bitness, and test on Access Runtime before rolling out to users. ACCDE vs ACCDB is not an either-or choice: developers work in ACCDB; end users run ACCDE.

Need help compiling, splitting, or deploying a production Access application? Contact our team for Access database deployment support — we build split-database architectures, compile ACCDE front-ends, and document backup procedures so you never lose the source ACCDB.