Title: FIBPlus as an alternative for access to Interbase and FireBird
Question: Components for access to Interbase and FireBird.
Answer:
FIBPlus as an alternative for access to Interbase and FireBird
FIBPlus as an alternative for access to Interbase and FireBird
Obverse and reverse of the same medal
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 some limits that is why a programmer who wanted to get a means oriented on Interbase architecture 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 BDE. Jason Wharton, the author of IBO, had to include in his library a considerable number of visual db-aware components. Besides this it was impossible to use IBO with standard visual db-aware 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 too much time to understand and get accustomed to mechanisms that work inside the library.
In contrast to IBO, FIBC was written for Delphi 3 from its very beginning and besides it did not contain any visual components. It had only db-engines so the architecture of FIBC classes was very simple and transparent for understanding. But it is necessary to mention that this library did not have many different functions, probably because its author Gregory H. Deatz did not consider it to be his chief task. I can assert with confidence that familiarization with FIBC was easy but its way of 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 between either IBO which automatized and hid many things at the same time limiting the possibility of their control, or FIBC which left almost everything up to developers but at the same time made them understand a lot of things on their own, though these things had already been realized in IBO. Personally for me these two libraries were sheer opponents in the approach of application development.
FreeIBComponents "for growth"
The appearance of Delphi 5 and Interbase 6.0 gave rise to the third product Interbase Express. I think everybody knows that FIBC served a basis for IBX. I can only guess about the reasons for this but partially it was due to open and simple architecture of FIBC. It was far easier to adapt it for those tasks, which developers on Delphi 5 had. 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. They also 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.
If not to take into consideration changes connected with Interbase 6.0, it was a kind of redecoration. About this speaks at least the fact that IBX inherited well-known FIBC bugs without any changes. For instance, even at present the Insert method in TIBDataSet of IBX behaves very strangely and this bug existed in FIBC from the very beginning. I think that a list of bugs can be easily continued but this article is not aimed at detailed analysis of both IBO and IBX. 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 is necessary to add that after release 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.
The golden mean or "a sudden leader"
That is really very difficult to choose between two alternative products. As usually one wants both simplicity of understanding and easiness of control. On one hand it is better to write less, on the other hand it is nicer to use such a mechanism, which allows more flexible avoiding of those defaults that suddenly start to hinder solving of some specific task.
It is high time to tell you about a sudden alternative of the above-mentioned products. Its name is FIBPlus.
The library developed simultaneously with FIBC and first was just a set of its additions and bud fixes. But after a while due to many corrections it required 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 automatized those standard routine tasks that every time while working required solution again and again.
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 a nice way of data editing in visual db-aware components. All necessary queries with requisite values of parameters will be automatically sent to a server. This process is absolutely transparent on every phase, but you have to fill all these properties manually every time. Frequently when often repeated this simple process becomes very laborious. 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 not needed. 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 UpdateSQL 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. When having some set modifying action such as, for example, deleting or inserting a new record in TpFIBDataSet, TpFIBUpdateObject clings to the set TpFIBDataSet and automatically sends the a necessary query to the server Of course, all its parameters will be automatically put from TpFIBDataSet to this query. 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 astounding and FIBPlus also works in the bounds of visual developing!
It is also very important to pay attention to the mechanism of CachedUpdates realized in FIBPlus. While using IBX you try to create a sample with a help of IBDatabase, IBTransaction and IBTable, then activate CachedUpdates in IBTable, connect to a database and open some table. After disconnecting from the database the table will close! CachedUpdates didn't work!
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 all changes will be sent to the server. Actually you can even realize CommitRetaining and RollbackRetaining on any Interbase versions because the rollback or commit of the transaction will not close the dataset connected with it, due to the cached data! 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 documentation of the library and there is a also an article about it available on
http://www.second-dream.ru/eng/fibplus/trans.htm.
Support of Boolean fields is also realized in FIBPlus. I do not mean emulation of editing of Boolean fields with the help of visual components such as TDBCheckBox, but the fact is that FIBPlus creates completely functional instances of fields of the TFIBBooleanField class (the direct descendant of TBooleanField). In a database it is only enough to determine a specialized domain in the name of which there is a word 'BOOLEAN' and the fields created with this domain will be considered to be Boolean. For example, for the developer a domain described as
CREATE DOMAIN T_BOOLEAN AS
SMALLINT
NOT NULL
CHECK (value in (0,1))
will be a base for real Boolean fields. The support of Boolean fields can be also deactivated.
The list of FIBPlus possibilities includes:
support of all Delphi versions from 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 stop using 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. It is the easiest and most convenient alternative of both IBO and IBX.
Serg Vostrikov.
Devrace Company