At its core, ODBC is a standardized database API specification. This API is independent of any specific database management system (DBMS) or operating system. While this explanation uses C, the ODBC API is language-agnostic. It builds on the Call-Level Interface (CLI) standards from the Open Group and ISO/IEC. ODBC 3.x fully supports these standards—unlike earlier versions, which partially implemented preliminary specifications—and includes features like scrollable cursors, which are essential for developers building screen-based database applications.
The ODBC API’s functions are implemented in DBMS-specific drivers created by developers. Applications use these drivers’ functions to access data in a way that doesn’t depend on the specific DBMS. A Driver Manager facilitates communication between applications and drivers.
It’s critical to understand that ODBC is designed to expose, not enhance, a database’s capabilities. Application developers shouldn’t expect ODBC to turn a basic database into a full-featured relational database engine. Similarly, driver developers aren’t required to add functionality beyond what the underlying database provides. However, developers creating drivers for file-based data (like Xbase files) must build a database engine with minimal SQL support. Additionally, the ODBC component in the Windows SDK (previously part of the Microsoft Data Access Components SDK) includes a cursor library that simulates scrollable cursors for drivers with specific functionality.
ODBC applications are responsible for handling cross-database functionality. ODBC itself isn’t a heterogeneous join engine or a distributed transaction processor, but its DBMS-independent nature makes it a foundation for building such cross-database tools.