Subject | Re: [ib-support] Re: working with date/time |
---|---|
Author | Helen Borrie |
Post date | 2002-01-16T02:38:41Z |
At 07:16 PM 15-01-02 +0000, serg_vostrikov_dr wrote:
After D3, it became possible to wrap the "native" IBO architecture around a TDataset descendant and thereby provide compatibility with the VCL components + emulation of the logical model that the BDE provided. A TDataset descendant on its own (FIB, FIBPlus, IBX) can't encapsulate that, even today. Instead of calling methods and setting properties, you have to write custom code handlers in every application.
The "current IBO model" is two distinct sets of component classes. The TIBO* classes are functionally equivalent to FIB, FIBPlus and IBX, meaning that you can build BDE-like applications with them and you use the native VCL and TDataset/TDatasource-compatible controls and data-aware components with them. But you also get access to some important native IBO properties and methods, session control, global property and attribute setting, OAT management and so on;
and the native IB_Connection is embedded in the database component, enabling you to add multi-transaction and multi-database capability too. It also means you can use the unbuffered cursor and DSQL components in your TDataset-compatible applications.
The "native IBO" classes - those with the TIB_* prefix are the fully VCL-independent ones, which have their own controls (70 or so at last count).
There is no deployment licensing at all.
So IBO is 25% cheaper than FIBPlus if you compare apples with apples...
I didn't want to raise these "price war arguments" but you did! And the record needed setting straight, didn't it? :)
Seriously, I think it's a mistake to choose connectivity on the basis of price alone. You should seriously evaluate them against your own requirements and their likely cost of ownership. Consider aspects like which editions of Delphi you have to buy, in order to use them (e.g. you can develop with native IBO using Personal edition!), what you get for your money (incremental searching built right into the data-access architecture of native IBO), the amount of code you have to write...
regards,
Helen
All for Open and Open for All
Firebird Open SQL Database ยท http://firebirdsql.org
_______________________________________________________
> Actually, FIBPlus is not similar to IBO. They have differentIn a way, you could say that...because, before Delphi 3, there were aspects of the Paradox database engine that you could not escape from because the TDataset wasn't virtual.
>class ideology and structure, because IBO has been projected for
>Delphi 2, which had not an abstract TDataSet. The current IBO model
>is an effect of this.
After D3, it became possible to wrap the "native" IBO architecture around a TDataset descendant and thereby provide compatibility with the VCL components + emulation of the logical model that the BDE provided. A TDataset descendant on its own (FIB, FIBPlus, IBX) can't encapsulate that, even today. Instead of calling methods and setting properties, you have to write custom code handlers in every application.
The "current IBO model" is two distinct sets of component classes. The TIBO* classes are functionally equivalent to FIB, FIBPlus and IBX, meaning that you can build BDE-like applications with them and you use the native VCL and TDataset/TDatasource-compatible controls and data-aware components with them. But you also get access to some important native IBO properties and methods, session control, global property and attribute setting, OAT management and so on;
and the native IB_Connection is embedded in the database component, enabling you to add multi-transaction and multi-database capability too. It also means you can use the unbuffered cursor and DSQL components in your TDataset-compatible applications.
The "native IBO" classes - those with the TIB_* prefix are the fully VCL-independent ones, which have their own controls (70 or so at last count).
There is no deployment licensing at all.
>FIBPlus was oriented on TDataSet paradigm fromA single FIBPlus licence costs $99 US. If you want only the IBO TDataset compatibility, you spend $149.50 for the IBO TDataset-compatible module (which actually includes a TIBOTransaction component, so you can have multiple transactions even if you just buy this module).
>the very beginning, that is why we do not need our own visual
>components and can use any third-party ones. May be it is the reason
>for IBO price - you buy a lot of components but will you ever use
>them? This is a good question, because when purchasing FIBPlus you
>pay only for fast and convenient IB engine, not for the visual stuff.
So IBO is 25% cheaper than FIBPlus if you compare apples with apples...
I didn't want to raise these "price war arguments" but you did! And the record needed setting straight, didn't it? :)
Seriously, I think it's a mistake to choose connectivity on the basis of price alone. You should seriously evaluate them against your own requirements and their likely cost of ownership. Consider aspects like which editions of Delphi you have to buy, in order to use them (e.g. you can develop with native IBO using Personal edition!), what you get for your money (incremental searching built right into the data-access architecture of native IBO), the amount of code you have to write...
regards,
Helen
All for Open and Open for All
Firebird Open SQL Database ยท http://firebirdsql.org
_______________________________________________________