--- In ib-support@y..., Helen Borrie <helebor@d...> wrote:

> 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!
I'm sorry, but I have not understood you again :). Perhaps we use
different terms, it is a big problem. Terms like "data
interface", "database engine" are too abstract and they do not have
exact definitions. So I use my meaning and you use yours :(.
What do you mean by "data interface"?

>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.")
Absolutely! Yes, I agree that such migration is simpler with the
help of IBO. But I think it is wrong way, because such migration
creates an illusion that SQL paradigm is similar to desktop
navigation mechanism! It is like automatic transmission in cars :),
it is easy but one day you can get big problems :) (I'm not
professional, I'm just quoting words of my friend, he is professional
sport-driver).
Creating SQL application you should project them like SQL
applications! Using FIBPlus "forces" developers to work in bounds of
correct client/server model. I know that using IBO you can also work
in correct bounds, but... you can work in bounds of BDE logic as
well. It can bring to mistakes.

>
> >>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..)
Really? I do not see. I just ment that nobody can automomize
everthing (and we also can not) but we automized a lot of things.
There are many ready solutions in FIBPlus and developers do not need
to write their code manually in many cases. For example, using
FIBPlus developers can drop one query (TpFIBDataSet), two
transactions (the first for data reading, the second for writing),
TDBGrid and enable AutoCommit mode. After opening TpFIBDataSet we
have one LONG read transaction. It can be read-commited and read-
only. The second transaction starts after any post. The modifying
query is executed, second transactions is commited, and TpFIBDataSet
automatically refreshes a current record. Thus all actual field
values are shown in the grid. No manual code, no deadlock, no long
modifying transaction.

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

You forget about difference in FIBPlus and IBO ideologies :). The
first thing is that we do not need to reopen queries after commit :)
if we use, for instance, two transactions. I do not know what you
mean by "domains interpretation" but we have not any problems with
fields, which use domains. Moreover, FIBPlus supports special boolean
domains and creates real boolean fields in applications. These fields
are boolean in the Delphi terms and any third-party visual components
interprete them like boolean (I mean any db-grids with markers,
checks, etc). Fields with defaults and without defaults, calculating
fields, null and not null fields, fields sizes - OF COURSE, FIBPlus
supports all of them! FIBPlus is not IBX, it is important difference.
And FIBPlus includes special options to manage such things. You can
enable and disable support of all field parameters if you need. By
the way, FIBPlus creates internal run-time structure and stores
necessary infomation about fields and tables. It allows to avoid
additional queries to a database while application works.

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

FIBPlus is not better or worse than IBO. They differ. IBO is not
better too. I do not know the best product. It can not exist, I
think. The problem is that sometimes some people :) tell not correct
things about FIBPlus. Perhaps it is because they do not know FIBPlus
well. I can understand it. But I can not understand why people try to
put a FINISH grade to a product.
You asked: "Did you full... etc, etc, etc". It looks for me
like "Hey, guys! FIBPlus did not full ... etc, etc, etc". But it
really did!

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

Straight facts and questions is what I like very much :). So could
I ask you straight too? :). Could you please (or may be someone of
readers) make your own performance tests and put them public? I
think, it would be interesting to a lot of people! It will allow to
optimize IBO and FIBPlus, to make them better than they are. I
already told about it.

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

Could you, please, ask me more exactly? I do not understand what do
you mean and what do you want to get to know. Do you mean TFields
collection? Why we need to avoid them? And what is "to avoid"? If you
use TDataSet descendants you can not avoid them :). You can create
them in run-time, in desing-time, free them after query is closed,
but you need them. It is VCL. I'm sure that IBO creates something
like TFields even in "IBO native" components.

> One important mechanism is its implementation of the concept of a

logical transaction. Except for cached updates (which are an
abomination in client/server)
I do not agree with it. Cached updates mode is just a mode of
postponed queries. All of them should be executed in the transaction
context, so I do not see any discrepancy with client/server.

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

That is, actually, if developers want a correct application they
should to rewrite it. They do it step-by-step in the simple cases,
but for really complicated applications it will be hard. I know that
and you know that - there are no simple ways to make correct
application, which is based on a wrong application. BDE is a wrong
way for creating efficient sql client/server application. Thus simple
components exchange does not solve a problem. Moreover, there are a
lot of cases when developers should re-design their application
entirely to avoid errors, which are inherited from old application.
It is a fact.

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

I understand what IBO visual controls are. But I can not agree
that it is a right way. Of course, it is a question of point of view.
But I think that we need to separate data, business rules and data
visual representation. Abstraction is the general thing in OOP.
TDataSet model is based on OOP. It is abstract. I understand that it
is not the most effective way for a specific data-source. But it
allows separating specific "databases" problems and "visual"
problems. Finally it can be more effective way than specific database
server controls.

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

Yes, I understand. But this problem can be solved more accurately,
I think. Visual columns attributes, which are depended on database
columns, do not require creating special visual controls. FIBPlus,
for example, allows setting and describing visual columns attributes
with the help of FIBPlus Data Repository. You can easy control fields
formatting, grid columns (alignment, titles, visibility), etc. And
the most important thing is that you can change these options without
recompilation of your application. All options are stored in a
database. Moreover, you can even store your queries in the database
and change them. FIBPlus components automatically use those changed
queries. Thus, we do not need special visual components, because
FIBPlus supports all of them and allows setting "special" parameters
like IBO. Three different blocks are:

[Data options block] - [Interpretation block] - [Visual Components
block]

We have wrote [Interpretation block] that is why we do not need our
own [Visual Components block].

>
> Creating TDataset-compatible data-aware controls, sure, that's a

different task.

>Heck, it's a whole industry!

Exactly! And I'm afraid all of us (I mean FIBPlus and IBO) will not
be able to compete with visual-controls vendors :).

>
> >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.
It is obvious for me :). If we choose a way we should go to the
finish :). Well, if you consider that visual-controls and report
builders are absolutely different things regarding data-presentation,
I will agree that IBO does not need its own report builder :)

> > 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. :))

:) Ok, I ment only that (as I can suppose) this limited (TDataSet
compatible only) IBO package does not include many special IBO
features. In particular, some special columns/fields properties,
which you told about. It looks for me like functionally limited
verison, which is not equal to FIBPlus. For instance, does it support
array fields in IBO TDataSet descendants? FIBPlus supports. We can
not compare apples and pears.

>
> > 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 have explained above what I ment.

>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?
No :). I'm sorry. I tried to tell you about FIBPlus approach. We
separated data, data-controls, and relations among data-controls.
FIBPlus automatically (and visually!) implements control over data-
controls and relations. So we do not need any special controls and
allow developers to manage such things flexibly. No problems. I
understand that integration among data-sources and data-controls
looks great (and it is really great!) but it is not the only way.
Thus the FIBPlus advantage is that we have all possible professional
controls and have special methods for integration, which are equal
(though we could not compare them exactly due to ideology difference)
to IBO. It is the good time to recall about prices :).

P.S: We can selflessly and even belligerently discuss some
IBO/FIBPlus questons but I hope it will not compel us to be opponents
at all things! We are proud of FIBPlus like Jason Wharton is proud of
IBO and we also are good people :), really! We worry about Interbase
and Firebird future as well. And we want to offer developers good
technology. It would be great to offer the best technology, but
actually I understand that it is not possible at all. People prefer
different things, different technologies, ideologies and nobody can
satisfy the all possible requirements. So, I hope we make our dispute
on "academical level" (it means that we do not touch any persons).

By the way, could you, please, answer my question not about IBO? :).
You wrote the 'typo' word and I saw this word before. Does it mean
a 'typing' mistake? Is it a slang word?

--
Sincerely yours,
Serg

Devrace - software for developers!
__________________________________
e-mail: sv@...
url : http://www.devrace.com/
http://www.fibplus.net/
http://www.athlant.com/