| Bug #23033 | SQLProcedures does not return the database name in the resultset | ||
|---|---|---|---|
| Submitted: | 6 Oct 2006 1:04 | Modified: | 30 Apr 2007 16:01 |
| Reporter: | Richard Brown | ||
| Status: | Closed | ||
| Category: | Connector/ODBC | Severity: | S1 (Critical) |
| Version: | 3.51 | OS: | Any |
| Assigned to: | Jim Winstead | Target Version: | |
| Tags: | SQLProcedures | ||
[6 Oct 2006 1:04]
Richard Brown
[6 Oct 2006 1:12]
Jim Winstead
Yes, it is currently hardcoded to always return an empty string for both catalog (PROCEDURE_CAT) and schema (PROCEDURE_SCHEM). But since a database is a schema in MySQL, that is what should be populated, not the catalog field.
[6 Oct 2006 1:35]
Richard Brown
Hi Jim, Saw your reply. Both PROCEDURE_CAT and PROCEDURE_SCHEM are null. Based upon what you said, PROCEDURE_SCHEM should be poplulated. Thanks... Rick
[20 Mar 2007 19:08]
Jim Winstead
Re-implementation of SQLProcedures using INFORMATION_SCHEMA
Attachment: bug23033.diff (application/octet-stream, text), 14.87 KiB.
[20 Mar 2007 19:12]
Jim Winstead
The patch I just attached re-implements SQLProcedures() by using INFORMATION_SCHEMA. My earlier note about schema == database isn't quite correct. While the server team is going forward with a plan for that to be true (see 'CREATE SCHEMA', etc, in recent releases), our existing connectors for JDBC and .NET, as well as the other ODBC catalog functions, use catalog == database. That's a mess that we'll leave for sorting out another day.
[2 Apr 2007 22:57]
Jim Winstead
The fix for this has been pushed, and will be in the 3.51.15 release. Thanks for the bug report.
[30 Apr 2007 16:01]
MC Brown
A note has been added to the 3.51.15 changelog.
