At 11:36 AM 16-01-02 +0000, you wrote:

> All professional, which working with Interbase/Firebird/Yaffil (do
>you know about Yaffil?),

Yes, I know about Yaffil.

>try to use in their application special
>Interbase features. Thus they do not use BDE emulation and any direct
>db-engine (like IBD, FIBPlus, etc) is the way for them to avoid BDE
>approach. If you agree with it you should make a conclusion that BDE-
>emulation is not an advantage :)

I think you missed the point in my previous email but one. The components emulate the logic of the BDE with respect to task handling - they CERTAINLY DON'T emulate the data interface! And - for example - IBO4 now provides emulation of (aaarrggh!!) BDE client-side filtering (in addition to the more powerful server-based filtering that it always had) because many people DO cross over to direct-to-API wanting to convert existing applications. The BDE's flaws soon show up once the conversion is done (a 5-minute job) so most will go through a period of eliminating code that is now unnecessary. One of the hardest things is to drag people away from TTables and client-side loops. (One of my favourite quotes is: "I want to use TIBOTable because I don't know SQL.")

The point to take on board is that TIBO lets you do the transition easily, if that is ones choice. And one of the (few) great things about the BDE is its task logic - an entire logical context in which the user begins at point A and moves through to point Z, unaware of the *physical* transaction at all.

>>regarding FIBPlus your
>information is wrong. You know that nobody can write his/her code
>without event-handlers at all, because components creator can not
>write all code by himself/herself. However we automize a lot of
>standard developer's tasks. We demostrated on Interbase RoadShow in
>Germany full functional examples without delphi code at all.

That's very good (even if these two statements appear contradictory..)

Did your full, functional examples take care of transaction management, positioning of cursors after commits, interpretation of domains, defaults and/or defeating Delphi's rules about non-null columns, field sizes, behaviour of buffers after refreshes, callback intervention, etc. etc., without adding a single line of code, thanks to properties and methods encapsulated right inside the components?

I'm not suggesting you have to prove that FIBPlus is "better" than IBO (or that IBO users need to prove anything, either) but I think it's a mistake for you devrace guys to try to write off your competition by misrepresenting it. Upon evaluation, there will be some for whom FIBPlus is the best answer and there will be others for whom it will be IBO...so please excuse me for putting some facts straight about some of your statements.

>> 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

> I'm sorry, but using TDataSet-classes is not building BDE-like
>applcations. This is VERY important thing. BDE is not equal TDataSet
>approach. TDataSet approach is only a way of visual data
>presentation.

What about persistent field objects? are you saying that you avoid them?

>BDE is a mechanism of transaction control, session
>organization, etc. You can use TDataSet descendants and not use BDE
>model.

BDE is actually a mechanism for transaction suppression and for pulling an enormous amount of stuff over to the client which doesn't belong there in a client/server application. It will be the objective of the serious client/server developer to achieve a server-centric model (which the BDE is not, by any stretch of the imagination). The BDE is Paradox - desktop database, no transactions, no reliable concurrency control - so it incorporates a vast amount of stuff to force client/server databases into a desktop-like framework. To do that, it has to use mechanisms that defeat the capabilities of the server.

One important mechanism is its implementation of the concept of a logical transaction. Except for cached updates (which are an abomination in client/server), the BDE developer can ignore transactions altogether and just focus on the user's task. The BDE takes care of all the stuff to hide the "problems" of transactions, at terrible cost to the performance and capability of the application.

Well, many developers LIKE that and, initially, think they can't live without it. IBO gives it to them (if they want or need it) without all the overhead that the BDE adds *and* without depriving them of the server's capabilities. It will be doing all the data-interface things in an entirely different way.

But they really *can* go through their units and their DFMs, change class names with a find-and-replace tool and be up-and-running five minutes later with no BDE. All their code will work, all their table components will be SELECTing * and Fetching All like crazy until they go to work on their dataset properties. It will be the same terrible client/server program that they had under the BDE and it will work. It will be full of handlers that they not longer need, but every bit of code will run. Their fancy third-party grids will be full of data and their buffer loops will be chugging away through thousands of records because their noisy, client-centric controls work perfectly.

> You know about FIBPlus TpFIBquery or IBX TIBSQL. They are
>unbuffered cursors and developers can use it without limits. It is
>the same too.

Yes, indeed. These components are magic bullets for client/server developers using FIBPlus or IBO. :))

> This is really important thing. On my opinion creation of visual
>components is an absolutely defferent task than creation of db engine
>components.

True for the TDataset model. The native IB controls are not like your TDatasource-compatible controls at all. Their entire behaviour is driven by the data. For example, you don't set column properties in IB_Grids, you set Field properties and column attributes in the datasets (if you want variations at dataset level) or right in the connection components, at domain or table.column level (or both) and then forget about properties in controls. You set search behaviour, relationship links or several kinds, all in the data access objects. IBO's data-aware controls know how to behave because they are truly data-aware. Their development is very closely integrated with the data access architecture. A Boolean shows up in a grid as a checkbox. Lookupcombos can be dropped right in the grid and, once the dataset-linking is done, they find their parent column and do just what you want a lookupcombo to do for that column...et al.

Creating TDataset-compatible data-aware controls, sure, that's a different task. Heck, it's a whole industry!

>Moreover, all of us know about great visual components
>and Report Builders (DevExpress or FastReprot, for example). By the
>way, why IBO does not contain native IBO report components? If
>consider IBO visual components more effective then IBO MUST contain
>its own report builder components.

What's the logic to that? What's the need? IBO works just fine with the report builder components already available, even poor old QuickReport. I'm too mean to buy a high-class reporting tool...and I have some very useful QR descendants that I use for my jobs. My apps are all native IBO *but* I drop a TIBOQuery (TDataset-compatible) onto my datamodule, right along with my TIB_ thingies. When the user has picked out a report set from my TIB_Grids, here's all I do to output the QuickReport:

MyIBOQuery.AssignSQLWithSearch(MyIB_Query);
MyIBOQuery.Open;
MyQR := TQRWhatever.Create;

...and off we go...

I've played with the FastReport evaluation and the ReportBuilder evaluation and I like them. I tried ReportPrinter Pro and didn't like it so well; but, when a customer finally agrees to pay for it, I will get FR or RB and I will be able to choose whether to use IBOQuery or IB_Query with them.

> I understand that creation of own visual components was only the
>way to add direct Interbase API support to Delphi. But it was correct
>for Delphi 2, now we have Delphi 6. Using native IBO visual
>components, I think, is not very good, because developer do not get
>modern visual capabilities. I hope you will not compare functionality
>DevExpress and IBO controls?

No; if I want DevExpress capability, I will buy (more) of their controls and build a hybrid application. DevExpress controls do magical things with client-centric GUIs - but I'm a Firebird/InterBase programmer, I don't write client-centric GUIs, so I don't need them. I do parameter selection panels and drill-downs so about my only use for a browsing interface is for control table maintenance. IB_Grid is more than adequate for that.

>> A single FIBPlus licence costs $99 US.
>Actually, not it costs $ 199

Yes - sorry about that - I posted a correction. :))

> What about services API, non-buffered queries, some special features?

If I want to use the services API (which I might, some day, when it works well) I will might write my own components; or I can use the IBX ones (as I have already done); or I can use yours if they work better than the IBX ones and you decide to market them as a module. I don't need the Services API for user applications, not even for security queries! With IBO I have non-buffered queries, more features than I can count PLUS a whole heap of capability that I can't get anywhere else. The world is full of blessings. Some days I just want to bounce off the walls, like Andrew Ferguson. :))

> No apples :). The core FIBPlus features are oriented on TDataSet
>support in contrast to IBO. So if you purchase FIBPlus you get
>EVERYTHING. If you purchase IBO Dataset-compatible module you get
>only a part of functionality.

Only part of what functionality? The BDE's?

>I do not want to say that
>IBO visual control are not professional, but you agree that visual
>components are not the most important part in IBO.

I believe that complex client interfaces are out of place in visual controls for client/server applications. I think you perhaps have not understood (until now) how different the native IBO controls are to the controls that you are used to. I made that error myself, for a long time, when I was locked into the "mindset" of the TDataset architecture - BDE, followed by FreeIBComponents, followed by IBX. I guess I might have gone the way of FIBPlus to improve on those, if I had not discovered IBO, its data-driven controls and a whole new perspective on client/server development that leaves TDataset for dead. Does that help to answer your question?

best regards,
Helen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________