MySQL Bugs: #7912: Using SQLDriverConnect leads to access violation in later ODBC calls

Bug #7912	Using SQLDriverConnect leads to access violation in later ODBC calls
Submitted:	14 Jan 2005 16:37	Modified:	20 May 2007 6:31
Reporter:	[ name withheld ]	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51.10	OS:	Windows (WinNT 4.0, Win 2000 Prof)
Assigned to:		CPU Architecture:	Any

Description:
Using SQLDriverConnect() to make a database connection
leads to access violation in later ODBC calls eg. SQLGetInfo().

Make a database connection with SQLConnect() works fine.

Bug seems not to depend on database or odbc configuration.
MyODBC release 3.51.10, earlier versions not tested.

How to repeat:
Use small C++ sample from below compiled with VC++ as console app.
Start sample and choose a valid MySQL 4/5 odbc datasource.
Rem.: replacing call to SQLDriverConnect() with SQLConnect() does not crash
--
Or use odbcte32.exe (mine is version 2.10) from the microsoft SDK.

---------------------------------------------

#include "windows.h"
#include "sql.h" 
#include "sqlext.h"

int main( int argc, char* argv[] )
{
   HENV henv=NULL; HDBC hdbc=NULL; SWORD iOutLen=0;
   TCHAR szConnIn[1000]={0}, szConnOut[1000]={0}, szInfo[1000]={0};
   RETCODE ret;

   SQLAllocEnv( &henv );
   SQLAllocConnect( henv, &hdbc );
   ret=SQLDriverConnect( hdbc, GetDesktopWindow(), (UCHAR*)szConnIn, 0, (UCHAR*)szConnOut, 1000, &iOutLen, SQL_DRIVER_PROMPT );
   if ( ret>=SQL_SUCCESS )
   {
      //-->> next line crashes with access violation in MYODBC3.DLL
      ret=SQLGetInfo( hdbc, SQL_DATA_SOURCE_NAME, szInfo, 1000, &iOutLen );
      //<<--
      if ( ret>=SQL_SUCCESS )   MessageBox( NULL, szInfo, "SQLInfo DSN", MB_OK );
      else                      MessageBox( NULL, szInfo, "SQLInfo returned error", MB_OK );
      SQLDisconnect( hdbc );
   }
   else
      MessageBox( NULL, szInfo, "SQLDriverConnect returned error", MB_OK );
   SQLFreeConnect( hdbc );
   SQLFreeEnv( henv );
   return 0;
}

Hi,

Thank you for your bug report.   
I have checked this and it is a bug with myodbc3 3.51.10.
We will try this quickly to resolving.

Best Regards

Similar setup here: Client uses 3.51.10 ODBC drivers on Windows XP SP2. Server runs MySQL 4.1.9-nt via TCP/IP on Win2K. Bug can be reproduced with clean server/client setup (both freshly installed).

Client uses SQLDriverConnect with an empty connection string to connect. Empty connection string causes MS-ODBC to prompt the user to select a datasource. I select a mySql Datasource and the ODBC driver opens the database (I verified by setting a breakpoint in myodbc3.dll). UID=root, database=test, DSN=mikado_sql etc...

Calling SQLGetInfo for SQL_SERVER_NAME works as expected and returns the ip address of the server (since I specified the ip-address in the DNS).

Calling SQLGetInfo for SQL_DATABASE_NAME crashes -> access violation.

I did some disassembly debugging (because I didn't want to compile the ODBC driver sources) and found that in file info.c, SQLGetInfo, line approx 356, statement case SQL_DATABASE_NAME: MYINFO_SET_STR(... dbc->database) the pointer dbc->database equals 0 which causes the access violation.

Why this pointer is zero I don't know. Debugging into my_SQLDriverConnect shows that the database name is known there and (as far as I can tell) is correctly assigned. It seems to get lost somehow.

BTW, a precompiled ODBC setup with debugging symbols would be helpful.

Testing using the provided test code and c/odbc v3.51.12 shows that there is still a problem here. The test does not segfault but fails to connect.

Feb 2007 and this bug still exists. The original crash has been fixed, I suppose, but, as the last commenter mentioned, the program still will not connect properly. This time, the original connection works fine, but after the default 8 hour timeout, a connection cannot be reestablished. In fact, the system is so hosed that closing all handles and re-establishing the entire environment doesn't work. I'm guessing the original call to SQLDriverConnect corrupts some internal data structure, which can never be repaired after that time. For now, I'll switch to SQLConnect.

Thank you for your bug report. This issue has already been fixed in the latest released version of that product, which you can download at

  http://www.mysql.com/downloads/

A note has been added to the 3.51.15 changelog.

Hi,

I've noticed the returned connection string from SQLDriverConnect is either truncated or corrupted. Is it correct?

I'm using MySQL ODBC 5.1 Driver (5.01.04.00)

Thanks.