The difference between the original and free versions of IBProvider

In the last six months there have been letters every month containing a questions about the difference between the original version of IBProvider and its free version - Free IBProvider. Since not everyone reads news after December 24, 2001, we decided to note here all the fundamental differences between these two versions.

Not technical special features are:

• the entire current functionality of commercial version to one extent or another is paid for the private and corporate users of InterBase;
• the free version was created due to another industrial program project, within the framework of which it was decided to write an OLEDB provider for InterBase, and personal time of LCPI developers.

InterBase support

Numeric data type (News)

• In Free version NUMERIC data types are presented as double. Therefore the Free cannot correctly process such columns with more than 15 significant digits. For example, NUMERIC(17,1).
• In the commercial version 16 bytes (39 significant digits) are used for NUMERIC. These 16 bytes completely overlap NUMERIC range of InterBase. It was used decimal numbers (128 significant digits), data presentation for internal conversions. Thus, the loss of significant digits is completely excluded. This provider correctly processes NUMERIC data both in ordinal columns and in columns with arrays.

TimeStamp data type (News)

• In the commercial version the loss of the fractional parts of seconds is excluded. It extends to both ordinal columns and columns with arrays.

Text data types (News)

• There is no explicit support of these data types in Free version. It means that the code page of operating system must coincide with database connection code page. Thus, it is impossible to organize transparent work, for example, from Windows with win1251 code page with database, created with the use of UNICODE_FSS code page.
• In the commercial version, the connection parameter " unicode_mode" is designed which determines the text data obtaining mode. Its default value is true. It means that all text data is forcedly converted into UNICODE with the use of the database connection code page. When writing the data, the provider forcedly recodes text with the use of the database connection code page. Thus, IBProvider makes it possible to organize interaction of the following kind: Recoding is applied to all the methods of text data transfer and presentation:
  • Ordinal columns
  • Arrays
  • BLOB-fields. Direct data transfer (the entire BLOB is loaded into RAM) and storage-objects data transfer (data return as COM-object)
  • Directly in query text. That is when preparing the query it is previously recoded with the use of the database connection code page.
  Pay attention: the database connection code page must coincide with the database code page.
  • InterBase does not recode BLOB-fields, therefore even if you set ctype=win1251 for UNICODE_FSS database, you will get BLOB-fields in UNICODE_FSS coding.
  If you do not want to get text data as UNICODE symbols, or provider does not support the database code page, determine in the connection string " unicode_mode=false".

BLOB data (News)

• In Free version, there is a simple enough scheme for conversion of text BLOB fields into UNICODE and back, in which processed data are completely put into RAM.
• In the commercial version there is a stream BLOB-fields conversion mechanism which almost completely excludes creation of intermediate copies.

Arrays (News)

• Free version incorrectly makes arrays for non-VARIANT compatible data types in " array_vt_type=false" mode.

Core differences

Data converter (News)

• Free version supports conversion with the use of binary presentation and storage objects only for BLOB-fields. i.e., in this format you cannot select data of ordinal columns - text, numerical, etc.
• The commercial version completely supports such conversions. i.e., you can select any column as binary or as COM-object. The presence of this support is required for interaction with Microsoft Client Cursor Engine, which support so-called ClientCursor.

Query parameters (News)

• In Free version there is a direct query processing mechanism which is not capable of processing these situations:
  • absence of parameter descriptions. The commercial version, in this case, will independently inquire the description from database server. See the initialization property of provider auto_param_describe.
  • nonconformity of real type of parameter and type of the parameter, indicated by user. In this case, the load lies on the database type converter. However, the converter is not capable of resolving some conversions. For example, when writing BLOB-field into ordinal text column and vice versa. Commercial version forcedly converts parameter data to the type, which database server expects. See the initialization property of provider force_param_describe. It simplifies the programming of queries to database.

Data transfer between provider and client (News)

• In the commercial version the data transfer mechanism is completely reconstructed to except the any search. For these, all the algorithms and service tables were rebuilt to use OLEDB data type identifier as a direct index.

Error processing (News)

• In Free, error processing is based on analysis of return codes between the inner layers of the provider. Exception traps are used, but only to process such fatal errors as, for example, out of memory. OLE Automation is used to pass error description from the provider. This makes it possible to return errors only as text.
• In the commercial version there is an absolutely different error processing mechanism based on C++ exceptions. This has radically simplified the provider internal implementation and made it possible to organize much stronger control over internal work. For the transfer of description from the provider, both OLE Automation and OLEDB services can be used. In the second case, the provider can return error collections and allow access to the error parameters.

Only in the commercial version of IBProvider

• Access to database metadata descriptions.
• Updatable rowsets.
• ODBC-extended SQL queries support. It is used in Crystal Report.
• Client Cursor Engine support.
• Possibility of using IBProvider as linked MS SQL server execution of shared queries to heterogeneous databases.

Conclusions

The great popularity of our free version Free IBProvider is a result of the following factors:

• From the moment of its release all the most serious errors were removed, which could cause unstabe work;
• the version has sufficient functionality to use it in more or less serious projects;
• Up to now, Free version is the only alternative for our commercial version. Moreover the version is absolutely free.

The Free version code base is taken from the commercial version 1.6, development of which by the end of 2001 had token two years. And, perhaps, the free version is the maximum that could be squeezed out of the architecture with the trivial translation of queries into IB API. Nevertheless, in Free there was the data storage scheme, that takes off the limitation to the size of rowset, which must be completely selected to client. Up to now this limitation exists in other popular access components.

For further development of the product, in the original version it was necessary to completely change its internal structure. Furthermore, it was necessary to reexamine the framework of the C++ usage during the creation of project, the free compiler from BCB5 proved to be much more reliable than its predecessors. As a result of making all these decisions, the functionality that is in Free is realized considerably more qualitatively in the original version and ensures a higher level of stability in extraordinary situations.

If you examine in detail the technical side of functionality, which is presented in the original version, but is absent in Free, then you will understand the following. In the year, which passed between the release of Free 1.5.2 and version 2.x, we not only completely broke any link between these two products, but also overcame that complication frontier, which, in our opinion, the developers of other access components for IB haven't even approached.