What were ActiveX Controls?

🗓️ 1. When did Microsoft phase out ActiveX?

• Internet Explorer: Support for ActiveX effectively ended when Microsoft introduced Edge (Legacy) in 2015, which dropped support for ActiveX entirely (en.wikipedia.org/wiki/ActiveXg).
• Microsoft 365 apps (Word, Excel, PowerPoint, Visio): As of October 2024 (Office 2024) and April 2025 for M365, ActiveX is disabled by default due to security concerns (Microsoft has been actively moving away from ActiveX).

ActiveX controls are not directly supported in Access 2010 and later and Microsoft strongly discourages their use with modern versions.
🔄 2. What replaced ActiveX in MS Access 365?
There isn't a one-to-one replacement for ActiveX controls, but for Access in Microsoft 365, Microsoft recommends using:
In summary:

• No new ActiveX in Access 365—stick with native controls and VBA.
• For extending beyond that, Web Add‑ins are the modern, secure approach.

Summary:

• ActiveX was phased out starting in 2015 (Edge) and fully disabled by default in Office 2024/2025.
• In Access 365, it's replaced by native form controls + VBA, with Office Web Add‑ins as the secure modern extension path.

Access had a great number of controls, as you have seen from the lessons in this module. You probably could get by using just the controls supplied by Access such as the Combo Box, List Box, Text Box, and Option Group controls.
But using Subform and Tab controls makes your form all that much more powerful. There is another set of controls that can be used for working with data on Access forms and reports. These controls were called ActiveX controls. ActiveX controls were for use not just with Access, but also with other Microsoft products, such as Visual Basic, and with non-Microsoft products.
ActiveX controls came in a variety of flavors. Some were used strictly for Web-type applications, and some were used with the Microsoft Office products. Access had one such ActiveX control built in known as the Calendar control.

Some controls, such as Calendar control, were data bound. This meant that the control had a Control Source property, just like a standard Access controls. The nice thing about this was that you could bind the controls to your fields in the record source. Then, for example, when you picked a new date, the Date field would be automatically updated.
Other controls required some Visual Basic for Applications (VBA) code in order for you to take advantage of them. Some controls, like the Calendar control, could give you greater power by using VBA code to manipulate them, but they did not require it. The Calendar control is the only control that was included with Access. There were Other sources for ActiveX controls as well.
In the next lesson, you will learn how to add the Calendar control to a form, binding it to a data source.

There were a number of places where you could get ActiveX controls from. The trick was finding ActiveX controls:

1. That worked with Access
2. That were data bound and required as little, if any, VBA programming

To be honest, in my experience, the majority of the ActiveX controls available did require some programming. The good news was that the controls usually came with sample code. Here are some sources for ActiveX controls:

1. Microsoft Corporation: The Microsoft Office Developer Edition had a number of controls, including Windows common controls for things such as file opening and saving.

No, **ActiveX Data Objects (ADO)** is **no longer being actively maintained or enhanced** by Microsoft. While **ADO is still supported for backward compatibility**, it is considered **legacy technology**.
## 🔎 Current Status of ADO ### ✅ **Still Supported** (but legacy)

• ADO (especially ADO 2.8, the last version) is included with Windows OS for legacy application support.
• You can still use ADODB.Connection, ADODB.Recordset, etc., in VBScript, Classic ASP, and older VBA/Access apps.
• Microsoft maintains minimal support—mostly bug/security fixes, not new features.

❌ **Not Actively Developed**

• ADO is not part of .NET Core/.NET 5+
• Microsoft recommends using ADO.NET (for .NET apps) or OLE DB with ODBC or newer APIs.

🔁 Microsoft's Official Guidance

Legacy Technology	Recommended Replacement
ADO (ActiveX Data Objects)	ADO.NET, Entity Framework, ODBC, or OLE DB for modern apps
ADO in VBA (Access/Excel)	Still usable, but DAO or modern APIs are encouraged

🧠 What to Use Instead (as of 2025)

Scenario	Recommended Approach
.NET applications	ADO.NET, Entity Framework Core
Access forms	DAO, linked tables, or ODBC connections
Web apps	Use ODBC with ASP.NET Core, or EF Core for abstraction
Legacy desktop apps (VB6, Access 2003)	ADO may still work, but modernization is advised

🔗 Reference
Microsoft has documented this deprecation informally by:

• Recommending ODBC and ADO.NET in their data access technology roadmap
• Discontinuing ActiveX embedding in modern Office and Edge

✅ Summary

• ADO is legacy: still works, but not recommended for new development.
• ADO.NET, ODBC, or Entity Framework are the modern alternatives.
• For Access developers: prefer DAO or migrate to modern data connectors.

ActiveX Data Objects, or ADO was an object model that was a successor to DAO and was intended to replace DAO. ActiveX Data Objects (ADO) was an object model introduced by Microsoft and intended as a successor to Data Access Objects (DAO).
Here's a bit more detail on why ADO was developed and its relationship with DAO:

• Why ADO was intended to replace DAO:
  • Universal Data Access (UDA): Microsoft's vision was to provide a unified way to access various data sources, not just relational databases. DAO was primarily designed for the Microsoft Jet database engine (used by Access), while ADO was built on OLE DB, a low-level interface that allowed access to a much wider range of data, including relational databases (SQL Server, Oracle, etc.), spreadsheets, text files, and even email.
  • Web and Client/Server Development: ADO was designed to be more suitable for multi-tier and web-based applications, offering features like disconnected recordsets, which are crucial for these environments. DAO was more focused on desktop applications.
  • Simpler Object Model: While not universally agreed upon as simpler, ADO aimed for a "flatter" object model with fewer objects but more properties and methods, potentially making it easier to learn and use for new developers.
  • Performance for Remote Data: ADO was generally considered better suited for interacting with remote data sources like SQL Server, especially after the removal of ODBC-Direct from DAO.
• The Reality of the Replacement:
  • DAO's Persistence in Access: For applications heavily reliant on the Jet database engine (Microsoft Access), DAO remained, and still is, the preferred and often more efficient choice. Microsoft even reversed its stance in later versions of Access (after some initial attempts to push ADO as the default) and brought DAO back as the primary data access method for Access projects.
  • ADO.NET: The landscape shifted again with the introduction of ADO.NET (part of the .NET Framework), which is an entirely different data access technology from "classic" ADO and bears little resemblance to it other than the name. This further complicated the "replacement" narrative.
  • Coexistence: Many developers ended up using both DAO and ADO depending on the specific task and data source. DAO for local Access databases and ADO for more generic data access, especially with external data sources.

In summary, ADO was a significant step forward in Microsoft's data access strategy, aiming for broader connectivity and suitability for modern application architectures. However, DAO never truly disappeared, especially within the Microsoft Access ecosystem, and continued to evolve (under the "ACE" database engine name in later Access versions).