Yes, however please note the following:
The standard way of quoting an identifier (column or table name) in SQL-92 is to use double quotes around the column or table name. This has two effects on the statement. First, the name quoted may be a reserved word, or may contain characters that are illegal in normal identifiers, spaces, and quotes, for instance. The second effect is to retain the case of the name. For example:
CREATE TABLE "Lower Table" ( "Field In Lower Case" INTEGER );
creates a table and column whose name retains the specified case. Normally, identifiers are mapped to their upper case representation before being saved in the metadata files. InterBase Dialect 3 enforces this type of behaviour, and allows the use of double quotes in this way. However, before Dialect 3, double quotes were synonymous with single quotes and were used to quote a literal. So, in dialect 1:
SELECT "Fred" from TABLE
would return a unnamed char column containing the string fred. But in dialect 3, the same statement would return the contents of a column called Fred (note case is significant) from the table.
The Easysoft InterBase ODBC driver, when connected using Dialect 1 and 2, scans the incoming SQL looking for double quoted identifiers and removes the quote. This may cause problems with applications that expect the old InterBase behaviour.
Older InterBase (pre version 6) servers did not support the rollback_retaining call. This means that if a rollback is executed on a connection, all statements for that connection terminate. This is the way it worked with the older ODBC drivers, and when connecting to a pre-6 server, the Easysoft driver behaves in this way. The driver uses this function, if available. This means that a rollback can be done, leaving all statements in their pre-rollback state.
The driver reports available operations to the application by using SQLGetInfo, so applications can take the appropriate action.
Before version 6, NUMERIC and DECIMAL types were mapped to the double representation. This caused problems, as the underlying InterBase representation is not of exact precision, whereas the SQL types are defined as exact precision. With InterBase 6, these types are now mapped onto INTEGER types, which maintains the precision. However, the precision is not stored in the metadata when the column is created, so with InterBase 6, a column defined as:
NUMERIC( 10, 2 )
has its precision (10) in the catalog, and this is reported through the ODBC API to the calling application. Older catalogs only stored the length of the storage type, so in the above case, it would be mapped to a double of length 8. The ODBC driver maps these types to the maximum available precision, so it's possible that the output of a SQLColumns call for the above column would indicate a precision of 18.
© 1993 - 2024 Easysoft Limited. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other trademarks and registered trademarks appearing on easysoft.com are the property of their respective owners.
