Yes, however please note the following:
The standard way of quoting a identifier (column or table name) in SQL-92 is to use double quotes around the column or table name. This has two effects. First, the identifier can be a reserved word, or contain characters that are illegal in normal identifiers, such as spaces and quotes. The second effect is to retain the case of the name. For example:
CREATE TABLE "Lower Table" ( "Field In Lower Case" INTEGER );
would preserve the case of these table and column names. 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 or 2, scans the incoming SQL looking for double quoted identifiers and remove quotes. This may cause problems for applications that expect the old InterBase behaviour.
Older InterBase (pre-version 6) servers don't support the rollback_retaining call. This means that if a rollback is performed on a connection, all statements for that connection will be terminated. This is the way it worked with the older ODBC drivers, and when connecting to a pre-6 server, the Easysoft driver will behave 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 ensures that precision is maintained. 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 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 case above, 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.
