[unixODBC-support] second opinion on quiktest.c

Nick Gorham nick.gorham at easysoft.com
Mon Feb 21 20:57:49 GMT 2005

Eric Sharkey wrote:

>I'm getting a failure report from quiktest.c's SQLStatistics test
>when run with my driver, and I think this is another example of a
>bad test, and not a problem with my code.  Can I get a second opinion
>on this?
>The relevant parts of the ODBC trace are here:
>                Entry:
>                        Statement = 0x8251018
>                        SQL = [Create Table Q142236 ( c01VARC VARCHAR(2147483647) NOT NULL)][length = 60 (SQL_NTS)]
>                Exit:[SQL_SUCCESS]
>                Entry:
>                        Statement = 0x8251018
>                        Catalog Name = [NULL]
>                        Schema Name = [NULL]
>                        Table Name = [Q142236][length = 7 (SQL_NTS)]
>                        Unique = 1
>                        Reserved = 1
>                Exit:[SQL_SUCCESS]
>                Entry:
>                        Statement = 0x8251018
>                Exit:[SQL_NO_DATA]
>What's happening is it executes a table creation command without
>quoting the table name, so the datasource downcases the name and
>creates a table named "q142236".  It then executes SQLStatistics
>without calling SQLSetStmtAttr to set the value of METADATA_ID, so
>it's still got the default value of FALSE (case sensitive) and it
>asks for SQLStatistics on the table "Q142236", which doesn't exist.
>It then complains when SQLFetch return SQL_NO_DATA, since SQLStatistics
>returns no rows.
>Is this the correct thing for my driver to be doing, given that
>it returns SQL_IC_LOWER to SQLGetInfo requests for SQL_IDENTIFIER_CASE?

Given that you return SQL_IC_LOWER, then yes, your driver is correct in 
what its doing.

I think quicktest started life against SQLServer where this would work.

It does hi-light the fact that a good test to cover multiple drivers is 
not a trivial matter.


More information about the unixODBC-support mailing list