ISAPI filter -> ODBC -> Sybase connection problem

[ray_bss]

WWW-service crashes while starts ISAPI filter dll (VC++ 6) when trying to connect to Sybase database through ODBC. I need to open ODBC connection on filter startup and keep it running to speed up base-related operations. So I call SQLConnect from DllMain and try to connect base (see example of code). It works perfect with Oracle database, but it doesn't work with Sybase (though compiled as Win32 Application it works with Sybase too). Code ======================================================================== #include #include #include #include #include #define ODBC_SUCCESS(rc)\ (((rc)==SQL_SUCCESS)||((rc)==SQL_SUCCESS_WITH_INFO)) HENV henv; HDBC hdbc; HSTMT hstmt; BOOL WINAPI DllMain(HINSTANCE hInst, ULONG ulReason, LPVOID lpReserved) { switch (ulReason) { case DLL_PROCESS_ATTACH: SQLAllocEnv(&henv); SQLAllocConnect(henv, &hdbc); RETCODE rc; // here www-service freezes rc=SQLConnect( hdbc, (unsigned char *) "DSN", SQL_NTS, (unsigned char *) "LOGIN", SQL_NTS, (unsigned char *) "PASSWORD", SQL_NTS ); if (!ODBC_SUCCESS(rc)) { ... // connection error } DisableThreadLibraryCalls(hInst); break; case DLL_PROCESS_DETACH: SQLDisconnect(hdbc); SQLFreeConnect(hdbc); SQLFreeEnv(henv); break; default: break; } return true; } BOOL WINAPI GetFilterVersion(HTTP_FILTER_VERSION * pVer){ ... } DWORD WINAPI HttpFilterProc ( HTTP_FILTER_CONTEXT* pFC, DWORD NotificationType, VOID* pvData ){ ... } ======================================================================== If somebody know how to solve this problem - help needed.

[Alois Kraus]

You should do your init work in HttpFilterProc. MSDN notes that it is dangerous to load any libraries in the DllMain function and .... Warning On attach, the body of your DLL entry-point function should perform only simple initialization tasks, such as setting up thread local storage (TLS), creating objects, and opening files. You must not call LoadLibrary in the entry-point function, because you may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, you must not call the FreeLibrary function in the entry-point function on detach, because this can result in a DLL being used after the system has executed its termination code. Calling functions other than TLS, object-creation, and file functions may result in problems that are difficult to diagnose. For example, calling User, Shell, COM, RPC, and Windows Sockets functions (or any functions that call these functions) can cause access violation errors, because their DLLs call LoadLibrary to load other system components. While it is acceptable to create synchronization objects in DllMain, you should not perform synchronization in DllMain (or a function called by DllMain) because all calls to DllMain are serialized. Waiting on synchronization objects in DllMain can cause a deadlock. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Otherwise, you can have the initialization routine create a named mutex, and have each routine in the DLL call the initialization routine if the mutex does not exist. Hope this helps

[basementman]

FYI, I have never been able to connect to Sybase via ODBC in either a filter or extension either. I think it has to do with different TCP/IP stacks used by CTLib. You might want to try Named Pipes?