Currently the answer is yes, however there are several points that should be considered.
 Quoted Identifiers
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, so for instance
CREATE TABLE "Lower Table" ( "Field In Lower Case" INTEGER );
Would create a table and column that retained the case. Normally identifies are mapped to their upper case representation before saving in the metadata files. InterBase Dialect 3 enforces this type of behavior, and allows the use of double quotes in this way. However before Dialect 3, double quotes were synonymous to 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 if a column called Fred (note case is retained) from the table.
The Easysoft DRIVER when connected using Dialect 1 and 2, will scan the incoming SQL looking for double quoted identifies and will remove the quote. It needs to do this to enable application that assume that double quotes may be used, to work. This however may cause problems with applications that expect the old default InterBase behavior.
 Rollback Retaining
Older InterBase (pre 6) servers did not support the rollback_retaining call. This means that if a rollback is performed on a connection, all statements on 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 function in this way. The driver will detect the availability of the function at the time of connection and if it is available will enable its use. This means that a rollback can be done, leaving all statements in their pre rollback state.
The driver reports the operations available to application via the SQLGetInfo call, so applications can at run time take the correct action as long as they check the functionally.
 Numeric Precision
Before version 6, NUMERIC and DECIMAL types were mapped onto double representation, this caused problems as the underlying representation is not of exact precision, whereas the SQL types are defined as exact precision. With IB6 these types are now mapped onto INTEGER types which ensures that precision is maintained. However the precision of the type was not stored in the metadata tables when the column is created, so with IB6 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 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 will indicate a precision of 18.
 As the Firebird project deviates further away from InterBase in its codebase then possible incompatibilities with the driver will no doubt emerge.