Yes, however please note the following:
The standard way of quoting a identifier (column or table name) in SQL92 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 );
would create a table and column that retained the 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, will scan the incoming SQL looking for double quoted identifiers and will remove 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 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 )
will have its precision (10) in the catalog, and this will be reported via 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 will map these types to the maximum available precision, so it is 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.
