Bug #8860 Generic SQLColumns not supported?

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 ...

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.

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.

Rewrite SQLColumns to fix various problems with handling input parameters

Attachment: bug8860.patch (text/plain), 27.33 KiB.

The fix for this bug has been committed, and will be in the 3.51.17 release.

Thanks for the bug report.

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.