In fact before Delphi 5 developers directed toward Interbase had at their disposal three db-engines: BDE, IBObjects and FreeIBComponents (FIBC). Universalism of BDE had and now has some limits that is why the programmer who wanted to get a means oriented on architecture of Interbase had to choose between IBO and FIBC.
IBO library contains rather complex structure of objects. In particular it is connected with the fact that IBO was written on Delphi 2. The library of classes of Delphi 2 did not allow writing descendants of TDataSet, which are not oriented on using BDE. Jason Wharton, the author of IBO, had to include in his library a considerable number of visual db-ware components. Besides this it was impossible to use IBO with standard visual db-ware components. After appearing of Delphi 3 the situation with IBO slightly changed. Jason Wharton added to it some TDataSet descendants, which could be used jointly with standard visual components. Nevertheless it did not entail serious architectural changes of the whole library. Because of a great functional potential and ideological "defaults" there was a certain drawback namely it took much time to get accustomed to and come to know the particulars of mechanisms that work inside the library.
In contrast to IBO, FIBC was written for Delphi 3 from the very beginning and it did not contain visual components. So it contained only db-engine and nothing else. The architecture of FIBC classes is very simple and transparent for understanding. But it is necessary to mention that this library does not have many different functions. Its author Gregory H. Deatz probably did not consider it to be a chief task. I think that we can assert with confidence that familiarization with FIBC was easy but solution of some practical tasks forced developers to programme on the level close to direct use of InterBase API.
So the developers had to choose either IBO which automatized and hid many things at the same time limiting the possibility of its control, or FIBC which completely gave the "reins of government" to developers but at the same time made them understand a lot of things, realized by this time in IBO, on their own. I should say that personally for me the two libraries were evident opponents in the sphere of ideology of the approach to application development.
The appearance of Delphi 5 and Interbase 6.0 helped out the third product: Interbase Express. I think everybody knows that FIBC was a basis for IBX. I can only guess about the reasons for such choice but I suppose that partially it was due to the open and simple architecture of FIBC. It was far easier to adapt it for tasks which put developers on Delphi 5. I know that probably I am mistaken but the fact remains - FreeIBComponents laid the foundation of IBX.
Without considerable changes of the inner structure of classes, IBX developers adapted the library for work with Interbase 6.0, put into operation a number of classes for compatibility with BDE, for example, TIBQuery, TIBTable, TIBStoredProc, and some other components intended for work with InterBase 6.0 services.
Actually if not to take into consideration changes connected with InterBase 6.0, it was a kind of redecoration. About it speaks at least the fact that IBX without any changes inherited famous FIBC bugs, for instance, even at present the Insert method in TIBDataSet of IBX behaves very strangely. This bug existed in FIBC from the very beginning. I think that the list of bugs can be easily continued but the detailed analysis of both IBO and IBX is not my aim. To obvious advantages of IBX we can ascribe the same simplicity of ideology as in FIBC. Its main shortcoming is its impossibility to be used in older versions of Delphi.
It remains only to add that after releasing of IBX FIBC stopped developing. Gregory H. Deatz did not continue adapting FIBC for InterBase 6.0 and the number of active products again became equal two, but at that time Interbase Express took the place of FIBC.
That is really very difficult to choose between two opposite and alternative products. As usually one wants both the simplicity of understanding and easiness of control. On one hand one wants to write less, on the other hand it is nice to use such a mechanism, which allows more flexible avoiding of defaults which suddenly started to hinder the solving of some specific task.
Here it is high time to tell about a sudden but pleasant alternative of the above-mentioned products. Its name is FIBPlus.
The library developed simultaneously with FIBC and first was just a set of additions and bud fixes of FIBC. But soon such changes started to require considerable changes that could not be solved anymore by simple inheriting. Since that moment FIBPlus got to become an independent product. Completely independent it became after its adaptation for work with InterBase 6.0 and Firebird.
What do we mean by FIBPlus alternatives? On one hand its author Sergey Buzadzhy tried to retain the simplicity and flexibility of FIBC, on the other hand he automatize standard routine tasks which a developer has to solve every time.
For instance, let's take an excellent mechanism of creating live queries, which exists in FIBC. Setting modifying queries in the InsertSQL, UpdateSQL (ModifySQL in IBX), DeleteSQL properties and an auxiliary RefreshSQL query we get the nicest possibility of data editing in visual db-ware components. All the necessary queries will automatically be sent to a server with all requisite values of parameters. This process is absolutely transparent on every its phase. But every time you have to fill all these properties manually. Frequently when often repeated it becomes as a matter of fact simple but very laborious process. In contrast to FIBC and IBX FIBPlus automatically either generates all modifying queries on the basis of conditions of SelectSQL, or does not do this if the developer does not need it. As you see the simplicity remains but FIBPlus helps to avoid manual work.
We can also examine an example connected with cascade data changing in several tables. It is obvious that in this case it is not enough to use only the Update query. That means that while using IBX it is necessary to write such event handlers as AfterPost, AfterInsert, etc. This task can be easily realized but it requires not very visual development. FIBPlus offers very simple and convenient alternative - the TpFIBUpdateObject component. It clings to the set TpFIBDataSet and automatically sends the query created by the developer when having some set modifying action such as, for example, deleting or inserting of a new record in TpFIBDataSet. Of course, from TpFIBDataSet to this query there will be automatically set all necessary parameters. The length and complexity of a queue of objects is limited only by the developer's fantasy. Each of these objects can work in the context of its own separate transaction and what is more nobody forbids you to connect up these objects to different databases! Flexibility of such approach is stunning and at the same time FIBPlus works in the bounds of visual developing.
It is also very important to pay attention to the mechanism of CachedUpdates realized in FIBPlus. Using IBX try to create a sample using IBDatabase, IBTransaction and IBTable. Then activate CachedUpdates in IBTable. Connect to a database and open some table. And then… disconnect from the database. The table will close. What about CachedUpdates?
In FIBPlus the same mechanism allows you to feel more comfortable. Using CachedUpdates you can disconnect from a database, change data, then connect again and send the changes to the server. Actually you can realize CommitRetaining and even RollbackRetaining on any versions of Interbase because the rollback or commit of the transaction will not close the dataset connected with it, the data is cached! In general the mechanism of transaction support in FIBPlus needs a special talk. Some facts about work with transactions in Interbase and their support in FIBPlus are included in the library documentation and also are available on our site.
Support of Boolean fields (for all InterBase/Firebird versions) is also realized in FIBPlus. I mean not emulation of editing of Boolean fields with the help of visual components such as TDBCheckBox, but the fact that FIBPlus creates completely functional instances of fields of the TFIBBooleanField class (the direct descendant of TBooleanField). It is only enough to determine in a database a specialized domain in the name of which there is a word 'BOOLEAN' and fields created using this domain will be considered to be Boolean fields. That means, for example, that a domain described as
CREATE DOMAIN T_BOOLEAN AS
CHECK (value in (0,1))
for the developer of a client application will be a base for real Boolean fields. Nevertheless the developer can deactivate the support of Boolean fields, he or she are not forced to use it always.
The list of FIBPlus possibilities includes support of all versions of Delphi starting with Delphi 3; centralized handling of errors; a repository of fields; a container of TpFIBDataSet events; local sorting; automatic formatting of numerical fields (and fields like Date/Time) by the set form; more intellectual approach for generating of TFields lists after executing of Select queries; improved Locate methods; automatic blocking of changeable records and many other things. Besides the developer always has a possibility to refuse to use this or that default in FIBPlus.
The balance between simple ideology and considerably increased functionality is such that FIBPlus can be called a golden mean, an easy and convenient alternative of both IBO and IBX.