Latest revision as of 11:05, 21 July 2020

Knowledge Base

PRB: Mouse Disappears or Machine Hangs When Connecting to ODBC

Article ID: 171859

Article Last Modified on 4/18/2003

APPLIES TO

Microsoft Visual Basic 4.0 Professional Edition
Microsoft Visual Basic 4.0 16-bit Enterprise Edition

This article was previously published under Q171859

SYMPTOMS

When trying to connect to an ODBC datasource from a datacontrol or the Data Access Objects (DAO), the mouse disappears, the machine hangs, or the machine General Protection Faults (GPF).

Attempting to connect to an ODBC datasource from Visual Basic 4.0 16-bit, causes the machine to behave as described above. It only occurs when a driver attempts to display a sign-on banner or a login dialog. For most drivers, a dialog is not displayed if a full connect string is provided, avoiding the problem.

CAUSE

The problem is due to the driver not correctly handling the window handle (HWND) that is passed to it on the SQLDriverConnect ODBC API call. The HWND parameter of this ODBC function call is defined in the ODBC 2.0 Programmer's Reference and SDK Guide as:

"Input. Window handle. The application can pass the handle of the parent window, if applicable, or a null pointer if either the window handle is not applicable or if SQLDriverConnect will not present any dialog boxes."

Because many ODBC driver vendors implemented their drivers such that a NULL HWND would never show dialogs, Visual Basic was forced to pass in a valid window handle. Because there is not always a window associated with a Visual Basic application, Visual Basic passes in the Desktop window handle. This causes a problem for many drivers. Many drivers simply take the HWND parameter passed in and use it in the calls to show their dialogs. The problem is that the dialog functions are documented such that NULL should be used when the Desktop window is to be used as the parent. Passing the Desktop window as the parent in the dialog calls can and does have adverse effects that are causing the problems listed above.

RESOLUTION

Upgrade to version 2.10.2401 of the ODBC Driver Manager (ships with Visual Basic 4.0 Professional and Enterprise) and have the ODBC driver vendor modify the driver such that it checks for the Desktop window and uses NULL for the parent window in the calls to the dialog functions. The SQL Server driver versions 2.10.2401 and greater does this correctly. The logic in the driver should be something like:

   RETCODE SQLDriverConnect(HDBC hdbc, HWND hwnd, UCHAR FAR * szConnStrIn,
SWORD cbConnStrIn, UCHAR FAR * szConnStrOut, SWORD cbConnStrOutMax,
SWORD FAR * pcbConnStrOut, UWORD fDriverCompletion)
   {
     //...... otherlogic
   if (GetDeskTopWindow() == hwnd){hwnd = NULL;}
    //rest of logic (to show dialogs)
   }

STATUS

This is an ODBC driver implementation problem. Contact the driver vendor for an updated driver. If the driver vendor does not have an updated driver, provide them with the information in the RESOLUTION section of this article.

NOTE: This problem does affect early ODBC Driver Manager (ODBC.DLL) and SQL Server driver versions. The problem was fixed in the 2.10.2401 versions of these components.

REFERENCES

Keywords: kbenv kb16bitonly kbprb kb3rdparty KB171859

@@ Line 56: / Line 56: @@
 The problem is due to the driver not correctly handling the window handle (HWND) that is passed to it on the SQLDriverConnect ODBC API call. The HWND parameter of this ODBC function call is defined in the ODBC 2.0 Programmer's Reference and SDK Guide as:<br />
 <br />
-&quot;Input. Window handle. The application can pass the handle of the parent window, if applicable, or a null pointer if either the window handle is not applicable or if SQLDriverConnect will not present any dialog boxes.&quot;<br />
+"Input. Window handle. The application can pass the handle of the parent window, if applicable, or a null pointer if either the window handle is not applicable or if SQLDriverConnect will not present any dialog boxes."<br />
 <br />
 Because many ODBC driver vendors implemented their drivers such that a NULL HWND would never show dialogs, Visual Basic was forced to pass in a valid window handle. Because there is not always a window associated with a Visual Basic application, Visual Basic passes in the Desktop window handle. This causes a problem for many drivers. Many drivers simply take the HWND parameter passed in and use it in the calls to show their dialogs. The problem is that the dialog functions are documented such that NULL should be used when the Desktop window is to be used as the parent. Passing the Desktop window as the parent in the dialog calls can and does have adverse effects that are causing the problems listed above.

Microsoft KB Archive/171859: Difference between revisions