MySQL Bugs: #28065: ODBC v3.51.14 cause Access Violation in MSDART.DLL with Delphi applications

Bug #28065	ODBC v3.51.14 cause Access Violation in MSDART.DLL with Delphi applications
Submitted:	24 Apr 2007 3:33	Modified:	22 May 2007 15:15
Reporter:	Roberto Franceschetti	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	3,51,14	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
Applications complied with Delphi 10 will suffer from the above Access Violations whenever they open an TADOQuery dataset. Sometimes the AV will occur on the first ADOQuery.Open statement, sometimes there needs to be a handful of open/close operations (less than 10) to cause the AV. The symptom is 100% reproduceable.

How to repeat:
Create a database named test.
From the server running MySQL, in the Windows Control Panel, ODBC Data Source Admin, create a System DSN called "test" pointing to the above database (I use "root" for username for testing purposes).

Use the following DDL below to create a simple table with 2 rows of data:

CREATE DATABASE IF NOT EXISTS test;
USE test;
DROP TABLE IF EXISTS `test`.`tbltest`;
CREATE TABLE  `test`.`tbltest` (
  `ID` int(10) unsigned NOT NULL auto_increment,
  `Desc` varchar(45) NOT NULL,
  PRIMARY KEY  (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `test`.`tbltest` (`ID`,`Desc`) VALUES 
 (1,'description 1'),
 (2,'description 2');

Now create a simple Delphi application that opens and closes for a few times a TADOQuery object that simply executes the following SQL:
SELECT * FROM tblTest WHERE ID=1;

You can download a sample application, that uses the hardcoded "test" DNS above, from:
http://www.logsat.com/pub/CrashODBC.zip
The zip contains the Delphi source as well. 

When executing the CrashODBC.exe file ourside of the compiler, with ODBC 3.51.14 you will get an "Unspecified Error". If you configure the Advanced options in the ODBC DSN to "Enable auto_increment NULL search" and run the CrashODBC.exe, you will see the actual Access Violation on the screen.

When debugging the program within Delphi, in either case of the ODBC configuration the Access Violation does show up the same.

**Please note that there are no issues with ODBC 3.51.12. We have a Delphi Application used by thousands of users that has *never* had a problem for the past years. But now as users upgrade to ODBC 3.51.14 the reports about this error are flowing...

The delphi code is to cause the error is as simple as the following:

unit frmCrashODBC;

interface

uses
  Controls, Forms, SysUtils,
  StdCtrls, ExtCtrls,
  ComCtrls,
  Windows,

  ADODB, Classes;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  Connection:TADOConnection;
  ADOQuery:TADOQuery;
  i:integer;

begin

  Connection:=TADOConnection.Create(Application);
  try
    Connection.LoginPrompt:=false;
    Connection.ConnectionString := 'Provider=MSDASQL.1;Persist Security Info=False;Data Source=test';
    Connection.Open;
    ADOQuery:=TADOQuery.Create(nil);
    try
      ADOQuery.Connection:=Connection;
      for i:= 1 to 20 do
      begin
        ADOQuery.SQL.Text:=LowerCase('SELECT * FROM tblTest WHERE ID=1;');
        ADOQuery.Open;
        ADOQuery.Close;
      end;
    finally
      ADOQuery.Free;
    end;
  finally
    Connection.Free;
  end;
end;

end.

Suggested fix:
We did not find a fix yet, other that uninstalling ODBC 3.51.14 and downgrading to 3.51.12

Delphi Executable and source code to reproduce error

Attachment: CrashODBC.zip (application/unknown, text), 357.40 KiB.

Hi Roberto and thanks for your report. Can you just clarify this for me, Delphi 10 is actually 2005?

Actually Delphi 10 would be Borland Studio 2006. Don't ask me why :-)
In any case, while I was googling to see if others were having similar problems, I have seen other cases from developers using Delphi 7.

Roberto, this seems to be more interesting than I thought as your test case crashes like reported... Consider this:
CREATE TABLE `tst` (
  `ID` int(11) NOT NULL auto_increment,
  `Name` varchar(50) default NULL,
  `File` mediumblob,
  PRIMARY KEY  (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
mysql> select * from tst;
+----+-------------+------+
| ID | Name        | File |
+----+-------------+------+
|  1 | nesto_drugo | NULL |
|  2 | Row 2       | NULL |
+----+-------------+------+

When I replace your table with this one I get no crashes! I need to think about this.

Tonci,

I see the same thing. If I add the field `File` as mediumblob to both the table I provided as a sample here, and to our real application, the error disappears..

Yes Roberto, the entire team is examining traces... I'll notify you when we come up with something.

As an FYI, the newly released ODBC v3.51.15 seems to have fixed the problem.

Roberto, glad it works. So now, I just need to figure out why...

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/

No one seems to be able to put the finger on the exact patch that fixed this problem in 3.51.15 so I'm closing the report.