Bug #8860 Generic SQLColumns not supported?
Submitted: 1 Mar 2005 12:52 Modified: 3 Jul 2007 21:10
Reporter: Mark Junker
Status: Closed
Category:Connector/ODBC Severity:S3 (Non-critical)
Version:3.51.11 OS:Microsoft Windows (WinXP Pro SP2)
Assigned to: Jim Winstead Target Version:

[1 Mar 2005 12:52] Mark Junker 
Description:
Hi,

when using a SQLColumns call with all arguments (except the first) set to NULL / 0, no
result will be returned.

Here's a part of the produced log file:

dbtest          ffc-6d0	EXIT  SQLColumnsW  with return code 0 (SQL_SUCCESS)
		HSTMT               01DB2528
		WCHAR *             0x00000000 
		SWORD                        0 
		WCHAR *             0x00000000 
		SWORD                        0 
		WCHAR *             0x00000000 
		SWORD                        0 
		WCHAR *             0x00000000 
		SWORD                        0 

dbtest          ffc-6d0	ENTER SQLFetch 
		HSTMT               01DB2528

dbtest          ffc-6d0	EXIT  SQLFetch  with return code 100 (SQL_NO_DATA_FOUND)
		HSTMT               01DB2528

BTW: What kind of SQLColumns calls are allowed?

Regards,
Mark

How to repeat:
Simply call SQLColumns(hStatement, NULL, 0, NULL, 0, NULL, 0, NULL, 0);
No data will be returned for SQLFetch ...
[2 Nov 2005 20:57] Yanfeng Chen 
I concur. Although I'm not quite sure how exactly an ODBC driver should response to such a
call, my application (Best Software MAS90 Visual Integrator) explicitly requires it when
it tries to bring up a list of all tables/columns.
[12 Jun 2007 3:20] Jim Winstead 
boosting the prio. SQLColumns() handles its arguments really poorly. it does not handle
the table name as a possible wildcard, and will totally choke on table names with any
special characters.

SQLColumns with all-null/empty arguments should give a list of all columns in all tables
in the current database.
[12 Jun 2007 23:53] Jim Winstead 
Rewrite SQLColumns to fix various problems with handling input parameters

Attachment: bug8860.patch (text/plain), 27.33 KiB.
[15 Jun 2007 21:45] Jim Winstead 
The fix for this bug has been committed, and will be in the 3.51.17 release.

Thanks for the bug report.
[3 Jul 2007 21:10] Paul DuBois 
Noted in 3.51.17 changelog.

SQLColumns() did not handle many of its parameters correctly, which
could lead to incorrect results. The table name argument was not 
handled as a pattern value, and most arguments were not escaped
correctly when they contained non-alphanumeric characters.