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:Microsoft Windows (Windows XP)
Assigned to: Bogdan Degtyariov
Tags: ADO
Triage: D3 (Medium)

[16 May 2004 2:17] Adrian Sandor
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 :)
[16 May 2004 16:44] Adrian Sandor
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.
[16 May 2004 19:10] Peter Harvey
VB examples

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

[16 May 2004 19:16] Peter Harvey
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.
[31 Aug 2004 19:56] Godofredo Miguel Solorzano
Verified using Access 2003.

Thank you for the bug report.
[29 Sep 2006 16:38] Eric Herman
I could not reporoduce using 3.51.12.

Created a ScriptUnit test, that should re-produce the fault, but the script passes just fine.
[29 Sep 2006 16:59] Eric Herman
ScriptUnit test demonstrating that the DefaultDatabase can be successfully set

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

[29 Sep 2006 17:12] Eric Herman
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.
[31 Jan 2007 13:56] Tonci Grgin
Provider does not support the property, ADODB.Connection
[31 Jan 2007 13:57] Tonci Grgin
Test case, c/ODBC 5.0.12.0

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

[7 Mar 2007 9:09] Bogdan Degtyariov
ADODB.Connection.DefaultDatabase works in MyODBC 3.51.12
[4 Apr 2007 2:51] Jim Winstead
Removing 3.51 from the version string, since it is fixed there.
[16 May 2007 11:08] Tonci Grgin
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.
[16 May 2007 11:30] Tonci Grgin
Once again I have to jump to my (big) mouth. The problem still exists in 5.0... Sorry.
[16 Oct 2007 11:33] Tonci Grgin
Retesting this with VBS script provided shows that 5.1APLHA works while 3.51.20 shows reported error.
[16 Oct 2007 11:36] Tonci Grgin
Actually it was 3.51.21
[16 Oct 2007 12:11] Bogdan Degtyariov
The bug appears only when DATABASE parameter is empty.
[16 Oct 2007 14:32] Bogdan Degtyariov
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.
[5 Nov 2007 21:20] Jim Winstead
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.
[27 Dec 2007 17:39] Bogdan Degtyariov
patch with the test case

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

[27 Dec 2007 19:08] Bogdan Degtyariov
patch with the test case version 3

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

[31 Dec 2007 13:49] MC Brown
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.