INF: Sharing ODBC Handles Among Several Applications

Last reviewed: September 9, 1996
Article ID: Q110475
The information in this article applies to:
  • Microsoft Open Database Connectivity, version 1.0

SUMMARY

When a Windows DLL is written such that it acts as an intermediary between several applications and ODBC drivers, it may be necessary to share connections among the applications. This article discusses the architectural blocks to sharing ODBC environment, connection, and statement handles among several applications through a user Windows DLL. It also discusses how a service provider DLL can be written so that it can access ODBC drivers and provide an interface to applications without sharing handles between applications.

MORE INFORMATION

ODBC Environment, connection, and statement handles are unique to tasks and cannot be shared among different tasks because the ODBC Driver Manager and ODBC drivers, when allocating memory for the connection, do not use the DDE_SHARE option on the GlobalAlloc(). For instance, in response to a call from an application, when a user DLL calls SQLAllocConnect() in the driver DLL, the memory is being allocated by the driver DLL in the context of the calling task, for example, the task that called the user DLL. In this scenario, another task that calls this same user DLL cannot then use this recently allocated connection handle to call ODBC functions.

If an ODBC connection needs to be shared among several applications, the following equivalent approach may be used. Instead of writing a DLL that shares various ODBC handles among applications, write an application that provides the same services as the user DLL would. Such an application would contain the calls to SQLAllocEnv(), SQLAllocConnect(), SQLAllocStmt(), and various other ODBC calls, and the other applications that need ODBC access can communicate via DDE with this DDE Server application. All ODBC function calls would then be encapsulated in the DDE Server application.

When writing a user DLL (without sharing ODBC handles among applications), it is important to have a separate ODBC environment for every task/application. Therefore, each application must make its own calls to SQLAllocEnv(), or have an initialization routine in the user DLL call SQLAllocEnv() in the ODBC driver in the context of the calling application/task.


KBCategory: kbusage
KBSubcategory:

Additional reference words: 1.00



THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 9, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.