In Windows, a handle is simply a pointer variable that refers to a data object the operating system uses to store context information. In a Windows application, handles are used to access data structures for which only Windows knows the details. The same is true with ODBC. Applications never look "inside" a handle, nor can they directly manipulate the data stored in the storage area to which the handle points (this concept is known as encapsulation in OOP languages). In Windows, handles are always managed by the operating system. Thus the application only needs to worry about securing the existence of the handle, and releasing the handle when is not needed for further operations.
The ODBC API allocation function(s) allow a driver to attach its own private data structure to each handle used. Therefore, applications always use the same kind of handle and the driver manipulates it accordingly. This approach has another benefit. The Driver Manager can use its own set of handles to manage each driver loaded and to provide the necessary mappings between applications and drivers. Handles also make it easier for application developers to obtain and process information when an ODBC function call fails. The handle approach in a multithreaded environment always makes it clear to both the application and the Driver Manager where context and error information should be stored. Additionally, when an error occurs, there is never a question about what the application is supposed to do. It should pass the handle that was used in the API function that generated the error to the appropriate ODBC error handling function.
The ODBC-API uses four types of handles:
As explained previously, these handles are meaningful only to the ODBC component that created them. An application's job is basically limited to keep these handles and pass them to the right component when needed.