You migrate your .mdb database to .accdb, open it in Access 2019 or later, and several forms look wrong. A calendar picker shows a broken box. A grid control displays nothing. A custom file browser throws an error. These aren't bugs in your data — they're ActiveX controls that no longer work in the modern format.
ActiveX controls were the standard way to add rich UI components to Access forms throughout the 1990s and 2000s: calendar pickers, data grids, rich text editors, file browsers, chart viewers. Many legacy databases are full of them. And in 2026, most of them are broken — either because the 32-bit OCX files they depend on aren't registered on modern 64-bit Windows, because Windows 11 blocked them under enhanced ActiveX security policies, or simply because the controls themselves were discontinued by Microsoft years ago.
This guide walks you through the full process: auditing your database for ActiveX controls, understanding what each one does, choosing the right replacement, and implementing it without breaking your forms or data.
ActiveX controls are COM components registered in the Windows registry. When they work, they work seamlessly — they look like native Access controls. When they break, they either show as empty boxes, throw registration errors on open, or silently fail to respond to user input.
There are three main reasons they break in 2026:
Most legacy OCX files were compiled as 32-bit only. Office 365 and Office 2019 ship as 64-bit by default. A 64-bit Access process cannot load a 32-bit ActiveX control. The registration might exist in the registry, but when Access tries to instantiate the control, it fails with a "class not registered" or "component object model" error.
Windows 11 introduced enhanced ActiveX security policies that block controls from loading unless they are explicitly trusted. This particularly affects controls embedded in forms that weren't loaded from a trusted location. Group Policy settings on managed machines can make this even more restrictive.
Microsoft stopped shipping many classic OCX controls with Office starting from Office 2010. The Calendar Control (MSCAL.OCX) was cut in 2010. The DataGrid control was deprecated around the same time. If your database was built in Access 97 through 2007, it likely depends on controls that simply don't exist on modern machines.
Before you can replace anything, you need a complete inventory. Don't do this manually — Access databases can have dozens of forms, each with multiple controls. Use VBA to automate the audit.
Open the VBA editor (Alt+F11) and paste this into a new module:
Sub AuditActiveXControls()
Dim db As DAO.Database
Dim frm As Access.Form
Dim ctl As Access.Control
Dim rs As DAO.Recordset
Dim sql As String
' Create a results table if it doesn't exist
sql = "CREATE TABLE IF NOT EXISTS tblActiveXAudit " &
"(FormName TEXT(255), ControlName TEXT(255), " &
"ProgID TEXT(255), ControlType INTEGER)"
CurrentDb.Execute sql
Set db = CurrentDb
Set rs = db.OpenRecordset("tblActiveXAudit", dbOpenDynaset)
Dim frmdoc As DAO.Document
For Each frmdoc In db.Containers("Forms").Documents
DoCmd.OpenForm frmdoc.Name, acDesign, WindowMode:=acHidden
Set frm = Forms(frmdoc.Name)
For Each ctl In frm.Controls
If ctl.ControlType = 100 Then ' acCustomControl = 100
rs.AddNew
rs!FormName = frm.Name
rs!ControlName = ctl.Name
rs!ProgID = ctl.CustomControlProgID
rs!ControlType = ctl.ControlType
rs.Update
End If
Next ctl
DoCmd.Close acForm, frmdoc.Name, acSaveNo
Next frmdoc
rs.Close
MsgBox "Audit complete. Results in tblActiveXAudit."
End SubRun this and you'll get a table listing every form, every ActiveX control name, and the ProgID — the unique identifier that tells you exactly which OCX file it's trying to load.
MSCal.Calendar.7 or MSFlexGridLib.MSFlexGrid. This tells you exactly what you're dealing with and which replacement applies.
Once you have the inventory, match each ProgID to its function. Here are the most common ones found in legacy Access databases:
| ProgID | Control Name | Function | Status |
|---|---|---|---|
| MSCal.Calendar.7 | Calendar Control | Date picker popup | Discontinued (Office 2010) |
| MSFlexGridLib.MSFlexGrid | FlexGrid | Read-only data grid | 32-bit only, blocked in 64-bit |
| MSComDlg.CommonDialog | Common Dialog | File/folder browser | 32-bit only |
| RichTextLib.RichTextBox | RichTextBox | Formatted text editor | 32-bit only |
| MSDATGRD.DataGrid | DataGrid | Editable data grid | Discontinued |
| Shell.Explorer.2 | WebBrowser | Embedded browser (IE) | Blocked (IE retired) |
| MSComCtl2.DTPicker | Date Picker | Date/time picker | 32-bit only |
| MSComCtl.ListView | ListView | List with columns | 32-bit only |
| MSComCtl.TreeView | TreeView | Hierarchical display | 32-bit only |
The replacement depends on what the control was doing in your form. Most have clean modern equivalents built into Access itself.
Build a small unbound pop-up form with a grid of buttons representing days. When a user clicks a date field, open this form modally. When they pick a date, write the value back to the calling form and close. It's more work than dropping in an OCX, but it's native, portable, and will never break due to OS upgrades.
Alternatively, use a simple text box with Format = "Short Date" and an AfterUpdate event that validates the input. Many users prefer just typing dates over calendar pickers anyway.
Access's built-in continuous form view is more capable than most people realize. Create a subform linked to your data table, set its default view to Continuous Forms, and style it to match your layout. For read-only display, a list box with the RowSource set to a query works well for simpler grids.
The Application.FileDialog object was added in Access 2002 and works correctly on all modern versions. Replace any Common Dialog usage with:
Dim fd As FileDialog
Set fd = Application.FileDialog(msoFileDialogFilePicker)
With fd
.Title = "Select a file"
.Filters.Clear
.Filters.Add "Excel Files", "*.xls;*.xlsx;*.xlsm"
If .Show = -1 Then
Me.txtFilePath = .SelectedItems(1)
End If
End WithFor simple rich text needs, a standard multi-line text box often suffices. For true rich text (bold, italic, fonts), the simplest modern approach is to store RTF as plain text and render it via an unbound OLE object linked to a Word document, or accept that Access forms aren't the right place for heavy text formatting and move that display to reports instead.
The embedded Internet Explorer WebBrowser control was retired along with IE itself. For databases that showed web content in a frame, the options are: open the URL in the default browser via FollowHyperlink, display the content in a separate report, or fetch the content via VBA and display in a text box.
These are the hardest to replace natively. For tree structures, a subform with indented display logic using a self-referencing table works for simple hierarchies. For column-sortable lists, a continuous form with sort controls at the top is the Access-native approach. If you need true ListView/TreeView behavior, there are commercial 64-bit compatible OCX alternatives — but these require purchase and deployment management.
LegacyLeaps scans your .mdb or .accdb and gives you a complete inventory of ActiveX controls — with replacement recommendations for each one — before you start any manual work.
Try the Free ScanWork through your audit results systematically, one form at a time:
After replacing all ActiveX controls, update your Trust Center settings to remove ActiveX from the trusted components list if you no longer use any. This reduces your attack surface:
Manually auditing and replacing ActiveX controls in a large database with dozens of forms is a multi-day project. LegacyLeaps automates the audit phase and handles the most common replacements programmatically during migration:
Application.FileDialog calls where the usage pattern is identifiableFor databases with a high density of ActiveX controls — 10+ controls across multiple forms — the time savings are significant. The scan takes under a minute. The automated replacements handle the routine cases. You spend your time on the judgment calls, not the inventory.
ActiveX controls rely on COM components registered in the Windows registry. Migration changes the database format but not the registry. If the target machine has 64-bit Office (which can't load 32-bit OCX files), stricter Windows 11 ActiveX policies, or simply lacks the OCX file because it was discontinued, the control fails to load.
Calendar Control (MSCAL.OCX), Microsoft FlexGrid (MSFLXGRD.OCX), Common Dialog (COMDLG32.OCX), Rich TextBox (RICHTX32.OCX), DataGrid (MSDATGRD.OCX), WebBrowser (Internet Explorer), Date Picker (MSComCtl2), ListView, and TreeView. Most are 32-bit only and incompatible with modern 64-bit Office.
Yes. Build an unbound pop-up form as a date picker, or use a text box with date validation. LegacyLeaps automatically replaces MSCAL.OCX with a VBA date picker during migration. Microsoft discontinued MSCAL.OCX in Office 2010.
Use VBA to loop through all forms and check for controls with type acCustomControl (100). Collect the ProgID from each control's CustomControlProgID property. The audit script above automates this across all forms in one pass.
Coming Soon
AI-powered code generation from .accdb files. Your data never leaves your machine.
LegacyLeaps scans your .mdb for ActiveX controls, VBA code, Jet SQL, and compatibility issues — then migrates to .accdb with everything preserved. Start with the free scan to see exactly what you're working with.
Download Free ScannerPractical fixes for legacy Excel and Access problems. No spam.