ADO usage scope:\nDoes ActiveX Data Objects (ADO) sit above OLE DB and support only scripting languages—not compiled programming languages?

Introduction / Context:
ActiveX Data Objects (ADO) is a high-level COM library that sits atop OLE DB to simplify data access. It is widely used from both scripting and compiled environments. This question probes a common misconception about ADO’s audience.

Given Data / Assumptions:

• ADO wraps OLE DB providers with Connection/Command/Recordset objects.
• COM libraries are callable from many languages that support COM interop.
• Scripting languages (e.g., VBScript, JScript) and compiled languages (e.g., Visual Basic 6, C++, Delphi) can all use COM components.

Concept / Approach:
ADO indeed “overlies” OLE DB, offering a simpler object model. However, it is not restricted to scripting. Classic ASP pages used ADO from VBScript, but desktop applications written in VB6, C++ (via #import or raw COM), and even early .NET via COM interop have also used ADO successfully. Therefore, the claim that ADO cannot be called by programming languages is incorrect.

Step-by-Step Solution:
Identify ADO as a COM automation-friendly library.List scripting clients (VBScript/JScript) and compiled clients (VB6/C++/Delphi) that can automate COM.Conclude that ADO is callable from both categories, not scripting only.

Verification / Alternative check:
Sample code in VB6 or C++ creating ADODB.Connection and ADODB.Recordset demonstrates compiled usage; classic ASP samples show scripting usage.

Why Other Options Are Wrong:
Limiting to .NET or ASP ignores the majority of ADO’s historical footprint. ADO.NET is a different, managed API and not relevant to this question.

Common Pitfalls:
Confusing ADO with ADO.NET; assuming scripting implies inability to use in compiled apps; overlooking 32-/64-bit COM registration mismatches.

Final Answer:
Incorrect