MySQL Bugs: #35300: Opening a table is very slow

Bug #35300	Opening a table is very slow
Submitted:	14 Mar 2008 19:52	Modified:	29 May 2013 6:15
Reporter:	Senén de Diego	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51.23	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
In Visual dBase a table is opened with the command:
"use table_name"

With older versions of the driver that command was very fast, but with the last version (and also with 3.51.22) it takes almost 20 seconds, only to open the table.

I've traced the ODBC logs both with version 3.51.12 and 3.51.23 and the ODBC commands logged are different.

And this is the first difference between both logs:

With the old driver the command issued is:

krnl386         4f8-588	ENTER SQLColumnsW 
		HSTMT               036A1DB0
		WCHAR *             0x00000000 
		SWORD                        0 
		WCHAR *             0x00000000 
		SWORD                        0 
		WCHAR *             0x036A2488 [       6] "albart"
		SWORD                        6 
		WCHAR *             0x00000000 
		SWORD                        0 

While with the new driver, this is the ODBC command executed:

krnl386         4bc-6b4	ENTER SQLExecDirect 
		HSTMT               03B32F18
		UCHAR *             0x02BF6CA8 [      -3] "SELECT * FROM `albart`\ 0"
		SDWORD                    -3

Is the whole table read into memory with the new driver?.

How to repeat:
Execute "use table_name" from Visual dBase.

ODBC log with old driver (3.51.12)

Attachment: SQL.3.51.12.LOG (application/octet-stream, text), 53.32 KiB.

ODBC log with new driver (3.51.23)

Attachment: SQL.3.51.23.LOG (application/octet-stream, text), 35.70 KiB.

Hi Senen and thanks for your report.

I will need complete test case attached here to figure out what's happening. In your first log you appear to use catalog function while in second you execute "SELECT" directly...

Senen, one more thing. Are you running against same server version and what is the server version?

Hello Tonci,
Thank you for your quick answer.
Yes, I'm running against the same server version (in fact, against the same server). The server version is 5.0.45-community-nt.
The only difference between both logs was the mysql-ODBC driver version installed in each of two different client machines.
I don't know what kind of test case can I post here. I have not control over the ODBC commands that are executed. 
In Visual dBase, data commands (such as "use table") are sent to the BDE (Borland Database Engine), which in turn, queries the mysql server through the ODBC driver.
I don't execute the "select * from albart" command directly. I only execute "use albart" and (I guess) it is the BDE who translates that into ODBC commands. But it does that differently depending on the version of the mysql-odbc driver used.

Senen, oh wow... So many 3rd party SW involved. Ummm, can you try from some other client, not Visual dBase (as I don't have it) and bypass BDE if possible. Can you tell me what version BDE is? Are you using different BDE aliases for different MyODBC versions or is it the same one? If it's the same on then IDAPI.cfg might have old info stashed somewhere... BDE is trouble.

Hi Senen,

Could you please provide us with full session log? For both driver versions.

And maybe table "albart" structure and status.

At the moment we don't have enough information to make any conclusions.

Thank you in advance.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.