Fill in the blank: ________ is Microsoft’s object-oriented data access interface that encapsulates data-server functionality for application developers (often built on top of OLE DB).

Introduction / Context:
Microsoft's data access stack historically includes ODBC (a C API), OLE DB (COM-based provider model), and ADO (ActiveX Data Objects), which offers an object-oriented interface designed for rapid application development. Choosing the right layer depends on whether you need a low-level provider contract or a high-level application object model.

Given Data / Assumptions:

• We seek an object-oriented interface intended for application code.
• It should encapsulate data-server functionality (connections, commands, recordsets).
• It commonly uses OLE DB under the hood.

Concept / Approach:
ADO (ActiveX Data Objects) provides objects like Connection, Command, and Recordset, exposing properties, methods, and events for data access. While OLE DB defines provider/consumer interfaces at a COM level, ADO simplifies that into a developer-friendly API that abstracts provider details and emphasizes productivity.

Step-by-Step Solution:

Verification / Alternative check:
Historical Microsoft documentation positions ADO as a higher-level interface over OLE DB, contrasting with ODBC's C APIs and DAO's Jet-centric model.

Why Other Options Are Wrong:

• ODBC: A C-level API, not object-oriented in the same sense.
• OLE DB: A low-level COM provider contract rather than a simple object model.
• JPCD: Not a standard Microsoft data API (likely a distractor).
• DAO: Tied to the Jet/Access engine and older scenarios, not the general-purpose abstraction ADO provides.

Common Pitfalls:
Confusing OLE DB (provider layer) with ADO (consumer-facing object model). Many ADO samples internally use OLE DB providers.

Final Answer:
ADO