Tim Bunce wrote: > > What does ODBC do about this issue? SQLGetInfo has a SQL_IDENTIFIER_QUOTE_CHAR information type that returns the current value:
"(ODBC 1.0) The character string used as the starting and ending delimiter of a quoted (delimited) identifier in SQL statements. (Identifiers passed as arguments to ODBC functions do not need to be quoted.) If the data source does not support quoted identifiers, a blank is returned." I *guess* if the client changes the quote bahviour during an active connection then this value will change to reflect that. The docs say that "Identifiers passed as arguments to ODBC functions do not need to be quoted" and futhermore, "they must not be quoted when passed as catalog function arguments". I *guess* identifier quoting is handled by the ODBC driver itself for these functions. When returning identifiers (such as in the Catalog Functions) then "Identifiers that are returned in the result set are not quoted, even if they contain special characters", but in this situation each identifier is returned as a distinct value within the row (eg $dbh->table_info) - we are talking about complex identifiers which might contain a catalog, schema (or owner) and table name in a single string (eg $dbh->tables). All DBI methods that accept identifiers should expect unquoted identifiers and if a method accepts a complex identifier (of more than one object such as table.column) then these identifiers should be passed as distinct arguments to the method (eg $dbh->primary_key). DBI methods should return unquoted identifiers unless the method returns a complex identifier (eg $dbh-tables) in which case the identifiers should be built using $dbh->quote_identifier. -- Simon Oliver
