Protect Your Access VBA Code from Reverse Engineering

Compile Access database macros into native DLLs - your business logic, SQL routines, and data export tools stay hidden inside compiled bytecode.

Why VBA Password Protection Fails for Access

Access databases with VBA modules face a unique risk: the .accdb file contains both data and code in a single package. The built-in VBA project password can be removed in seconds using freely available tools, exposing your business logic, SQL queries, validation rules, and data processing algorithms.

Even converting to .accde/.mde format offers limited protection - the VBA code is compiled to p-code but remains recoverable with specialized decompilers. For commercial Access applications and database tools, this is not acceptable.

The Solution: Compile Access VBA to Native DLLs

VBA Padlock goes beyond .accde protection. It compiles your VBA modules into native 32-bit and 64-bit DLLs, replacing readable source code with protected bytecode. The compiled DLL has full access to Application.CurrentDb, DoCmd, and the entire DAO engine - your code works identically, but cannot be decompiled.

Your Access database (.accdb) keeps its forms, reports, queries, and tables intact. VBA Padlock analyzes the database copy-first - the original is never opened for writing - and saves a protected copy containing generated wrappers with the same names and signatures, plus the VBA bridge that loads the DLL. Users open the database and work normally - they never see your protected code.

Open

Open your existing .accdb in VBA Padlock. It extracts and analyzes your macros procedure by procedure, working on a copy - the original is never opened for writing.

Review & Produce

The Protection Review shows what moves into the DLL and what stays. Click Produce to compile the DLLs and save a protected copy with generated wrappers and the VBA bridge.

Distribute

Ship the protected copy (MyDatabase_protected.accdb) with the bin/ folder. Users open the database normally - the DLL handles everything.

See It in Action

Left: a function that now runs from the compiled DLL. Right: VBA in the protected database calling it through the bridge.

Protected Code (VBA Padlock)

Function ExportToCSV(TableName, FilePath, Delimiter)
    Dim DB, RS, Stream, FieldCount, i
    Set DB = Application.CurrentDb
    Set RS = DB.OpenRecordset(TableName)

    Set Stream = CreateObject("ADODB.Stream")
    Stream.Type = 2
    Stream.Charset = "UTF-8"
    Stream.Open

    ' Write header row
    For i = 0 To RS.Fields.Count - 1
        If i > 0 Then Stream.WriteText Delimiter
        Stream.WriteText RS.Fields(i).Name
    Next i
    Stream.WriteText vbCrLf

    ' Write data rows
    Do While Not RS.EOF
        For i = 0 To RS.Fields.Count - 1
            If i > 0 Then Stream.WriteText Delimiter
            Stream.WriteText Nz(RS.Fields(i).Value, "")
        Next i
        Stream.WriteText vbCrLf
        RS.MoveNext
    Loop

    Stream.SaveToFile FilePath, 2
    Stream.Close: RS.Close
    ExportToCSV = True
End Function

Caller Code (Access VBA Editor)

Sub ExportCustomers()
    Dim FilePath As String
    Dim Success As Variant

    FilePath = CurrentProject.Path _
        & "\Customers.csv"

    Success = VBAPL_Execute( _
        "ExportToCSV", _
        "Customers", FilePath, ";")

    If Success Then
        MsgBox "Export complete!", _
            vbInformation
    End If
End Sub

Access VBA Protection in Action

Real examples from Access projects protected with VBA Padlock.

Microsoft Access database using compiled and protected VBA logic — Protected Access database running with compiled DLL code.

VBA Padlock script editor showing Access VBA code extracted for compilation — Extracted Access VBA code in the VBA Padlock script editor, ready to compile.

What You Can Protect in Access

VBA Padlock supports all Access VBA scenarios - from database utilities to complete commercial Access applications.

Database Business Logic

Protect proprietary validation rules, calculation engines, and workflow automation that power your Access applications.

Data Export Tools

Secure CSV, JSON, and XML export routines that process sensitive database records with custom formatting.

SQL Query Engines

Hide advanced query builders, dynamic SQL generators, and reporting logic inside compiled DLLs.

Form Automation

Forms and reports keep working unchanged. Event handlers stay in the database and call your protected code through generated wrappers.

Access Application Distribution

Distribute complete Access applications with protected business logic. End users run the .accdb file normally.

Licensing & Activation

Add hardware-locked license keys, trial periods, and online activation to any Access VBA project - built into the DLL.

Access-Specific Notes

Use Application.CurrentDb (not just CurrentDb) inside compiled scripts.
The Access database must be in a writable location for license storage.
Filter out system tables (MSys* prefix) when iterating TableDefs.

Need a step-by-step walkthrough?

Read the dedicated Access tutorial

Follow the full process to protect an Access database with VBA Padlock.

Watch the video tutorial

A 13-minute walkthrough of the concepts using the earlier manual workflow. Since 2026.2, the analysis, wrappers, and bridge injection happen automatically when you click Produce.

Frequently Asked Questions

Can VBA Padlock compile VBA code from an Access .accdb database?

Yes. Open your .accdb in VBA Padlock: it extracts and analyzes your VBA modules, compiles them into 32-bit and 64-bit DLLs, and saves a protected copy of the database with generated wrapper procedures and the VBA bridge. Your forms, reports, and queries stay intact, and your original file is never modified.

Does compiled code have access to Application.CurrentDb?

Yes. Your compiled VBA code retains full access to the Access object model including Application.CurrentDb, DoCmd, CurrentProject, and the DAO engine. One important note: always use Application.CurrentDb (not just CurrentDb) inside compiled scripts.

How do I protect Access forms that call VBA functions?

You do not have to change your forms. VBA Padlock analyzes each procedure, moves the eligible ones into the compiled DLL, and replaces them with generated wrappers that keep the same names and signatures. Form event handlers stay in the database by design and keep calling the same procedures, which now run from the DLL.

Can I distribute a protected Access application to end users?

Yes. You distribute the protected copy of your database (for example MyDatabase_protected.accdb) alongside a bin/ folder containing the compiled DLLs. End users only need Microsoft Access (2016 or later, 32-bit or 64-bit). No runtime or additional software is required. You can also add license key activation to control distribution.

Does VBA Padlock protect my SQL queries inside the Access file?

VBA Padlock protects VBA code that generates or executes SQL queries programmatically. Queries stored as Access query objects remain in the .accdb file. To protect sensitive SQL logic, keep it in VBA procedures rather than saved Access queries - the analysis moves those procedures into the compiled DLL.