> I believe in IBO, though, and I'm adding a couple of comments about what
> are the areas I think should be improved to gain the favor of IBX users
> and former BDE developers:
>
> - definitely decouple the UI from the data access layer; provide the
> current UI controls, support and enhance them, but also make it easy,
> dead easy for anyone to make IBO-aware versions of their controls. Much
> easier than Borland's DataLinks, I mean. Publish and document a clean
> and simple
> interface and have component makers produce IBO versions of their
> controls. I think something is being done lately in this respect, but no
> one would think about developing an IBO application with a grid other
> than the IB_Grid, for example.

I am working towards this. It is actually pretty easy to make a control IBO
aware because I have built so much into the datalinks. I just need to
document it.

> - remove quirks and peculiarities, and most of all reduce the reasons of
> incompatibility between versions. I think this is getting better with
> the latest versions, but I can see it isn't optimal. A few examples of
> what I see as "quirks" are the behavior of RecordCount in the TDataSet
> based components, the '::SQL::' prefix in filters, the exposure of the
> IB bug on stored procedures.

These items are resolved. The RecordCount issue is more correct now than it
was before. It has been brought into harmony with what the BDE users are
expecting and still provides the preferable behavior that I like by setting
a single property.

As for the ::SQL:: issue. I never documented that the Filter property was
for anything other than the syntax that the BDE would allow. Because of the
way I implemented it it made it easy for people to include SQL in there and
get away with it. Then, when I made some additional improvements so that my
filter parser was more thorough and allowed more flexibility it started to
parse the text always instead of using a cheap tactic to see if it could
ignore parsing. Thus, I started messing up those who had been using the
Filter property for undocumented purposes. In order to accommodate this,
instead of tell people "too bad" I opted to add the ::SQL:: prefix. I think
this was a wise move. In short, if you are using the Filter property as
documented there would have been no adverse changes to deal with at all.

As for RecordCount and IBX, I really don't think there is any comparison
there because it simply doesn't work in IBX at all. It doesn't have the
parsing smarts that IBO does and so it either forces you to fetch all the
records into the dataset or deliver an inaccurate value. Did you really
intend to convey the notion that IBX was better than IBO where record counts
are concerned?

> - give dignity to the TDataSet-based flavor of the components. It is
> easy right now to take advantage of both flavors in the same app, but
> your current view seems to be that they are to be used for BDE
> compatibility only (and I would suggest to rethink the layering:
> TDataSet compatibility and BDE compatibility should not be mixed, I
> think), where I know that the option of using out-of-the-box data-aware
> controls is just as much important.

TDataset has much from the native IBO layer that goes beyond mere BDE
compatibility. I surface as much as I can to them and I think I'm already
doing a pretty good job here. I make it so that you can even access the
internal dataset to tinker around.

What do you suggest I do that I am not already making available in the
TDataset portion of IBO? The greatest benefit of making IBO's TDataset
components TTable, TQuery, TDatabase, etc. compatible is all that Borland
has done to document them applies to IBO. Thus, I have hordes of free
documentation that readily applies to my components there. This is a very
great benefit, not to mention it is so easy for people to move to IBO from
the BDE.

> - there seems to be plenty of room to make the wrong thing with IBO:
> just too many stringlists in which to code behavior, as opposed to
> compiled Pascal code. The TDataSet-based architecture generally appears
> more fool-proof and with cleaner interfaces in this respect. But I think
> this is a design personal preference, after all. OTOH, the easiest it
> becomes to work with IBO, the less time you have to spend in this list.

You probably don't understand the reason there are stringlists they way they
are. Once you grasp the whole vision of IBO in how you approach the
development and design of an entire application you will love the features
that look awkward to you.

I agree that they do allow errors to be accidentally entered and it might be
a little confusing at times tracking some things down to fix them but once
used to it things fall together very quickly. Especially when you discover
how to make global settings.

Also keep in mind that the string lists are only parsed at Prepare time.
Once prepared there are static containers for the pertinent information.
Thus, there is a little bit more resource usage but no loss of performance
by using them. And, in fact, for a large application I dare say that there
is less overall resource usage because so much of your applications settings
can be stored globally instead of spread all over in all the datasets.

> - improve design-time support.

Agreed. This is always much to improve here. I would like to eventually get
it to where there doesn't have to be so much poking around in string lists.
These really are just intended for raw storage. But, because of how things
are scoped it makes it a little tough to make a GUI that harnesses the full
power of the entire IBO settings model.

> > Why am I doing this? First of all because I get asked it a lot and

second

> > because I owe it to the community to give people as much accurate
> > information as possible so that people can make the most accurate and
> > informed decisions as to what tools they commit to.
>
> As I said earlier, I'll take advantage of any opinions I can find in
> this thread, but I find your words a little too biased to be "accurate".

Although I am biased, I have been quite careful about what I have said.
What do you feel I am incorrect about?

> I think this is pretty much acceptable, since you must know very well
> what you are talking about, but a more comprehensive view of things must
> be derived from all the opinions I can find in this list and elsewhere
> (among the rest, one of the things IBX lacks is a strong user community,
> so it is a little difficult to balance merit opinions).

I think that is fair enough.

> Also, it would turn to be useful if you would state exactly where IBX is
> immature and poorly written (if it doesn't take too much time ;-)),
> because this could serve to improve both IBX (I know you aren't
> interested in that) and your credibility as an accurate reporter.

John Kaster and I had dinner one night. He thought it was funny how every
time I complained about certain thing in IBX that this was simply used as
their list of things to work on. My comment at the time was, what's good for
Borland I suppose is good for me... I don't feel so much that way any
longer. Mostly because I am starting to feel like Borland doesn't care so
much about the success of me as a third party provider. I do a lot to make
Delphi and InterBase enjoyable and powerful to use. And, what thanks do I
get from them? Well, for starters, I submitted two excellent session
abstracts to present in the Borcon next year. What happened? Both rejected.
Not sure why because I have had excellent reviews on previous sessions I've
presented there.

I have been at this long enough to know when things are right or wrong and I
am not content any longer to sit around and see such a mess made to most
everyone's expense. If I drive the IBX people hard enough to totally rewrite
it so that it is more respectable I suppose that is fine. Either this needs
to happen or they need to concede that it is what it is, poorly architected
and not usable except for simple/lightweight stuff.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com