Thanks. I think the DBI should follow ODBC where it differs from SQL/CLI in areas where ODBC is not likely to change. This is probably one of those places.
Tim. On Fri, Mar 15, 2002 at 12:46:29PM +0100, Steffen Goeldner wrote: > Steffen Goeldner wrote: > > > > > P.S.: It seems I'll have TO DO some 'empty string' research. > > This is yet another case where ODBC and SQL/CLI differ :-( > > ODBC is quite clear about pattern value arguments: > > <http://msdn.microsoft.com/library/en-us/odbc/htm/odbcpattern_value_arguments.asp> > > | Passing a null pointer to a search pattern argument does not > | constrain the search for that argument; that is, a null pointer > | and the search pattern % (any characters) are equivalent. > | However, a zero-length search pattern - that is, a valid pointer > | to a string of length zero - matches only the empty string (""). > > ODBC says not much about empty strings in ordinary arguments in > general. However, the doc's for special catalog functions say > (e.g. for SQLColumns): > > | If a driver supports catalogs for some tables but not for others, > | such as when the driver retrieves data from different DBMSs, an > | empty string ("") denotes those tables that do not have catalogs. > > ODBC is quite silent about empty strings in identifier arguments. > > In my opinion, ODBC treats empty strings always as restriction > criteria, i.e. they match the empty string. > > SQL/CLI gives very precise rules how arguments must be handled. > Attached is a perlified version of these rules for SQLColumns(). > As you can see, arguments of length zero are ignored when building > the predicate. Thus, empty strings will not restrict the result > set. > Matching an empty string is only possible if METADATA_ID is TRUE > and the argument is an empty quoted identifier ('""'). > > > Steffen
