Re: thorny problem with table_info implementation

On 03/09/2013 11:43, Martin J. Evans wrote:
> On 03/09/13 09:38, Tim Bunce wrote:
>> On Mon, Sep 02, 2013 at 08:53:18PM +0100, Martin J. Evans wrote:
>>> On 02/09/2013 20:27, Martin J. Evans wrote:
>>>>
>>>> Now, table_info() with no arguments is not mentioned in the DBI pod so
>>>> you could say that is undefined behaviour but it is a little late for
>>>> that now as DBD::ODBC uses it in test code and as far as I know, so do
>>>> others. However, to fix the initial bug I cannot know when empty
>>>> strings
>>>> are supposed to be undef/NULL and when they are supposed to be empty
>>>> strings. So I can fix the bug as shown but only if I change DBD::ODBC
>>>> test code from table_info() to table_info('%', '%', '%', '%') and I
>>>> cannot change anyone elses code.
>>>
>>> Correction, in that last paragraph (I did warn you), I should have
>>> said table_info() to table_info('%', '%', '%') i.e.,
>>>
>>> table_info('%', '', '') returns catalogs only
>>> table_info('', '%', '') returns schemas only
>>> table_info('', '', '', '%') returns types only
>>> table_info('%', '%', '%') returns everything
>>> table_info() did return everything due to workaround in DBD::ODBC
>>> but fixing bug ends up in table_info() returning nothing.
>>
>> How about changing your test code to table_info('%', '%', '%', '%')
>
> because that does not work. It would need to be table_info('%','%','%')
> (or table_info(undef, undef, undef, undef) for it to work. In ODBC the
> table type needs to be null or all types to get everything. Obviously
> changing the test code is easy.
>
>> and treat table_info() a special case that triggers a warning?
>
> hmm, I warned I might be having a bad day. As soon as I read that I
> thought how do I do that as I'd forgotten there is a table_info method
> in DBD::ODBC itself. It appears all the problems are DBD::ODBC specific
> as I missed the code that set the parameters to q{} if not defined.
>
>> Tim.
>>
>
> Thanks and sorry for noise.
>
> Martin
>

Pushed changes to github and will try and find time to release updates 
tomorrow. This started from 
http://stackoverflow.com/questions/18450002/retrieving-available-table-types-schemas-and-catalogs-using-dbiodbc-table-i. 
This actually found a bug in the easysoft sql server odbc driver re: 
calling SQLTables with % as the table_type - ask easysoft support for an 
updated driver if you need this fix. If no complaints I will release a 
new DBD::ODBC with new test cases in the next week.

Martin
-- 
Martin J. Evans
Wetherby, UK