MySQL Bugs: #3780: reading or setting ADODB.Connection.DefaultDatabase is not supported

Bug #3780	reading or setting ADODB.Connection.DefaultDatabase is not supported
Submitted:	16 May 2004 2:17	Modified:	31 Dec 2007 13:49
Reporter:	Adrian Sandor	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	3.51.21	OS:	Windows (Windows XP)
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any
Tags:	ADO

Description:
I'm using ADO 2.8 (in ASP) and MyODBC 3.51.07 to connect to mysql 4.0.18
I am able to open the connection and perform queries, but whenever I try to read or set the DefaultDatabase property of the Connection object, I get the error:

ADODB.Connection error '80040e21'
Provider does not support the property. 

How to repeat:
I use a file dsn:
[ODBC]
DRIVER=MySQL ODBC 3.51 Driver
UID=[my username]
STMT=
OPTION=0
PORT=
PASSWORD=[my password]
SERVER=localhost
DATABASE=
DESC=

I connect like this:
cnn.Open("FILEDSN=mysql.dsn");

Whenever I try to read (e.g. for displaying) cnn.DefaultDatabase, or try to set it (e.g. cnn.DefaultDatabase="mysql"), I get the error I mentioned

Suggested fix:
make it work, I don't know how :)

I tested on a Windows 2000 system with mysql 4.0.16; with both myodbc 3.51.06 and 3.51.07, and the same code, I get this error:

ADODB.Connection error '800a0cb3'
Object or provider is not capable of performing requested operation.

VB examples

Attachment: BUG-3780.tar.gz (application/x-gzip, text), 3.83 KiB.

I used VB to test this (see attached file). I was able to produce the problem (and variations of it).

1. Problem does not occur with a regular DSN - needs FILEDSN.
2. Problem does not occur upon first connection but rather once the connection has been closed and connection opened. Possibly same connection handle being reused or a new handle but same environment.

This may be a problem in driver with freeing connection handle - perhaps not. Needs more investigation.

Verified using Access 2003.

Thank you for the bug report.

I could not reporoduce using 3.51.12.

Created a ScriptUnit test, that should re-produce the fault, but the script passes just fine.

ScriptUnit test demonstrating that the DefaultDatabase can be successfully set

Attachment: ScriptUnitBug3780.tar.gz (application/x-gzip, text), 948 bytes.

Although this originally was reported against the current version, that was a long time ago. The problem seems to have been fixed some time prior to 3.51.12 release, so please give the latest a try.

Thank you for taking the time to report a problem.  Unfortunately you are not using a current version of the product you reported a problem with -- the problem might already be fixed. Please download a new version from http://www.mysql.com/downloads/

If you are able to reproduce the bug with one of the latest versions, please change the version on this bug report to the version you tested and change the status back to "Open".  Again, thank you for your continued support of MySQL.

Provider does not support the property, ADODB.Connection

Test case, c/ODBC 5.0.12.0

Attachment: wikitest.vbs (application/octet-stream, text), 1.70 KiB.

ADODB.Connection.DefaultDatabase works in MyODBC 3.51.12

Removing 3.51 from the version string, since it is fixed there.

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/

Attached test case works as expected both with 3.51.15 and mysql-connector-odbc-5.0-win32-nightly-20070510.

Closing the report.

Once again I have to jump to my (big) mouth. The problem still exists in 5.0... Sorry.

Retesting this with VBS script provided shows that 5.1APLHA works while 3.51.20 shows reported error.

Actually it was 3.51.21

The bug appears only when DATABASE parameter is empty.

ADODB determines the default database by parsing the connection-out string. If there is no DATABASE=<something> the DefaultDatabase property is not supported.
Trying to fix that.

i think the patch is overkill, and i really dislike the idea of having an option that turns on multiple different behaviors.

for this bug, i think just adding a call to reget_current_catalog() before accessing dbc->database would be enough.

patch with the test case

Attachment: patch3780v2.diff (application/octet-stream, text), 2.90 KiB.

patch with the test case version 3

Attachment: patch3780v3.diff (application/octet-stream, text), 4.85 KiB.

A note has been added to the 3.51.23 changelog: 

Setting the default database using the DefaultDatabase property of an ADO Connection object would fail with the error Provider does not support this property. The SQLGetInfo() returned the wrong value for SQL_DATABASE_NAME when no database was selected.