Limitations of DAO, DAO SDK in NT Service or with threads
This article was previously published under Q156138 On This PageSUMMARY
With the release of MFC Open Database Connectivity (ODBC) in Visual C++
4.2, you can use both MFC and the MFC ODBC classes within the multithreaded
environment of a Windows NT Service. Neither the MFC Data Access Objects
(DAO) classes nor the DAO SDK are thread-safe because the underlying Jet
engine is not thread-safe and cannot be used in a Windows NT Service.
The techniques presented here are valid for any multithreaded environment with the MFC ODBC classes, not just a Windows NT Service. The remainder of this article explores the following three areas relating to using MFC-based database classes within a Windows NT Service:
MORE INFORMATIONHow a Windows NT Service WorksA Windows NT Service consists of code that is roughly similar to the following:
When a service is started, the Service Control Manager waits for the
primary thread of the service to invoke a call to
StartServiceCtrlDispatcher(). This call triggers the creation of a named
pipe whose purpose is to provide a communication channel between the
service and the Service Control Manager. The primary thread acts as a
control dispatcher for the service. The service receives control requests
from the Service Control Manager via the control handler (callback
function). In addition, the StartServiceCtrlDispatcher() invokes a
secondary thread that contains the entry point of the service as specified
by the SERVICE_TABLE_ENTRY structure. If the StartServceCtrlDispatcher()
call succeeds, the StartServiceCtrlDispatcher() call in the primary thread
does not return until all running services in the process have terminated.
Any attempt to use database classes within a running service must not only be thread-safe, but must also be able to operate in the secondary thread. How to Use MFC ODBC in a Multithreaded EnvironmentWith the release of Visual C++ 4.2, both MFC and the MFC ODBC database code is safe to use in a multithreaded environment. However, you should keep the following points in mind:
Why MFC DAO or DAO SDK Cannot Be Used in a Multithreaded EnvironmentDAO version 3.x is a single-threaded in-process server and was originally written for Access 1.x and 2.0 and Visual Basic 3.0, both of which are single-threaded. This means that clients (MFC DAO or DAO SDK) can use DAO via custom interfaces only from the first thread in the process that initialized COM, that is, the "primary" thread.If the client has already initialized COM in the primary thread and then calls CoCreateInstance in the secondary thread asking for the IDAODBEngine interface, CoCreateInstance fails. This fails because COM sees that DAO is not marked as apartment or free threaded in the registry, calls DllGetClassObject from the primary thread, gets the IDAODBEngine interface, tries to marshal it back to the secondary thread, and fails. See the Knowledge Base article listed in the REFERENCES section of this article for more information. REFERENCES
For additional information, please see the following articles in the
Microsoft Knowledge Base:
169395 (http://support.microsoft.com/kb/169395/EN-US/)
PRB: Thread Safety for DAO/Jet 3.5
System Data Sources136481 (http://support.microsoft.com/kb/136481/EN-US/)
INF: Running ODBC Applications as Windows NT Services
Impersonating a Valid Windows NT User96005 (http://support.microsoft.com/kb/96005/EN-US/)
Validating User Accounts (Impersonation)
Using MFC Database Classes in a Console Application152696 (http://support.microsoft.com/kb/152696/EN-US/)
HOWTO: Using the MFC Database Classes in Console Applications
Why DAO Cannot Be Used in a Multithreaded Environment151407 (http://support.microsoft.com/kb/151407/EN-US/)
PRB: DAO Must Be Used in Primary Thread
Using MFC ODBC with an ISAPI DLL160906 (http://support.microsoft.com/kb/160906/EN-US/)
HOWTO: Use MFC 4.2 ODBC Classes in an ISAPI DLL
APPLIES TO
| Article Translations
| ||||||||||||||||||||||||||||||||||||||||||||||||

Back to the top
