Simon Oliver wrote:
>
> Steffen Goeldner wrote:
>
> > QuotedIdentifierStart == QuotedIdentifierEnd in ODBC (see
> > SQLGetInfo, SQL_IDENTIFIER_QUOTE_CHAR).
> > Of course, your proposal is more general.
>
> Yes, in most cases they are the same and SQL92 says they should be but
> there are cases like MS Access that use [ ], although it does accept
> double quotes too. I thought it would help make it more flexible for the
> sake of a byte or two of RAM.
>
As I said, your proposal is more general - I like it.
BTW: My Access driver returns '`':
use DBI;
my $dbh = DBI->connect('dbi:ODBC:test') || die $DBI::errstr;
print $dbh->func( 17, GetInfo ); # DBMS_NAME
print $dbh->func( 29, GetInfo ); # IDENTIFIER_QUOTE_CHAR
ACCESS`
> >> QuotedIdentifiers (boolean, inherited), disabled by default
> >> indicates if quoted identifiers are in use
> >
> > ???
>
> This attribute indicates if the current connection is using (requires,
> allows) quoted identifiers. If it is not set then the QuoteIdentifier
> method shopuld return the identifier unquoted.
>
> Some DBMSs and APIs such as JDBC and Trabnsact SQL in Sybase Adaptive
> Server Enterprise don't allow quoted identifiers by default and this
> feature must be enabled by setting a database option for the connection.
>
Thanks for the clarification! Sounds like some databases require this.
> This is one of the reasons why this issue of quoting needs to be cleaned up.
>
> >> TableIdentifiers (arrayref, inherited), [1,2] by default
> >> list of identifiers that uniquely describe a table,
> >> an array of zero based column indexes as returned from
> $dbh->table_info()
> >
> > We reflected on this point a long time: Do we really need that?
> > Maybe a driver returns a catalog name, but does not permit it in
> > SQL statements? Do you have an example?
>
> Yes, MS Access returns the the path to the database file as the catalog
> name, Sybase Studio Anywhere sets this to null, and MS-SQL server uses
> the name of the Database. So for Access connections, including the
> catalog identifier would cause an error, but having the option of using
> the catalog name (not currently implented in tables()) might be useful
> when dealing with MS-SQL server connections.
>
If a DBD Writer knows, the database does not support catalog names in
SQL statements, then table_info() should return NULL for TABLE_CAT.
In this case, tables() does not need TableIdentifiers()!
O.k., DBD::ODBC may cause troubles, because it depends on (possible
buggy) ODBC drivers. In this case, the user would be able to provide
a workaround via TableIdentifiers(). But he could simply ignore the
TABLE_CAT field! Whatever workaround he uses, he has to implement
some knowledge about the database and cannot write generic code
anymore.
BTW: My Access driver allows that:
$sth = $dbh->prepare('SELECT * FROM `C:\tmp\test`.`test`');
Steffen G�ldner
Olga Voronova
