Jason,

> I would like to solicit the opinions of others on why you chose IBO over IBX
> and what the advantages you feel that you enjoy by having made that choice.
> I have nothing to lose by campaigning these benefits and plan to do so. I've
> been much to passive to date on how I have addressed this topic.

this is something that I'm sure will turn really useful to me; I am not
using IBO in any real production environment at present (yet), but I
happened to study it for a couple of seminars and classes on Delphi and
IB that I made (and plan to make more in the future).
Still, I feel extremely unsure about how IBO appears to be designed
since I must admit that it is more comfortable to work with the
dataset-based architecture of IBX. Perhaps it's just (bad?) habit on my
part.
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 favour of IBX users
and former BDE developers:

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

- 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 behaviour of RecordCount in the TDataSet
based components, the '::SQL::' prefix in filters, the exposure of the
IB bug on stored procedures.

- give dignity to the TDataSet-based flavour of the components. It is
easy right now to take advantage of both flavours 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.

- there seems to be plenty of room to make the wrong thing with IBO:
just too many stringlists in which to code behaviour, 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.

- improve design-time support.

> 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".
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).
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.
Regards
--
____
_/\/ando