Bug #8860 Generic SQLColumns not supported?
Submitted: 1 Mar 2005 11:52 Modified: 3 Jul 2007 19:10
Reporter: Mark Junker Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:3.51.11 OS:Windows (WinXP Pro SP2)
Assigned to: Jim Winstead CPU Architecture:Any

[1 Mar 2005 11: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 19: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 1: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 21:53] Jim Winstead 
Rewrite SQLColumns to fix various problems with handling input parameters

Attachment: bug8860.patch (text/plain), 27.33 KiB.
[15 Jun 2007 19: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 19: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.