Jason,
I guess I have led you a bit OT in this thread; by reading my message
and your reply I can see it isn't really an IBO vs IBX discussion. This
is unfair on my part, so please accept my apologies for that, and thanks
for the clarifications.
Anyway, I'm just trying to help you by playing this part; I'm still a
BDE guy after all, for the largest part of my IB development.

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

Here's how I see it: users never should have bothered about the
existence of "buffers". It is documented that a BDE/IB application that
calls RecordCount causes a fetch-all. I would have just arranged things
that way. I would not have touched the IsSequenced property, because I
think you can begin implementing enhancements only after reaching full
compatibility, and enhancements should not sacrifice compatibility.
I understand that you introduce this kind of improvements for the
better, but some users could maybe feel unsure about it.

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

The first one: the dataset should fetch all the records as soon as you
call RecordCount. It isn't efficient, it isn't smart, but it's not
inaccurate and it's just what one expects to happen.
Apart from that, we would not be discussing about these finer details if
the compatibility between the BDE and IBX wasn't a joke. I thought that
was clear enough to all readers.

<SNIP clarifications on the Filter property>

I suppose it isn't feasible to recognise the kind of the filter string
(internal or SQL) by simply parsing it (thus avoiding the need for a
prefix).

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

I'd separate the TDataSet-compatible components and the BDE-compatible
components. Since Delphi 3 Borland has done much work to introduce a
clear distinction, and I think you would benefit from that. I am aware
that there would not be many differences between these two flavours
right now, but we know that OO software engineering is all about
foreseeing the change.
This would also allow one to use the TDataSet-compatible components
because he needs to use a certain report engine, or data-aware
components, without bothering about the BDE and BDE compatibility at
all.
In short, layering is good in my vision.

> 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; it just scares the developer, and the available documentation
is not sufficient.
Note: I have yet to read your new beginner's guide, which I'm sure is a
step in the direction of better documentation.

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

Performance and resource usage are not issues for me at this level. It's
just that the interface is huge and scary, and doesn't give any hint
about what stringlists one should fill and how. I believe the learning
curve isn't optimal because of this great difference in "vision" between
IBO and the base (and third-party) VCL available.
I agree that once you catch it you appreciate the power it gives you. No
doubt. But this is the feeling I had when I started studying IBO: I was
scared. IBX did not scare me. I suppose that could happen to others as
well.

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

You are not incorrect, but:
- you don't seem in the position (nor in the mood) to frankly talk about
technical details of IBX. You just say it sucks, as I understand it.
This could well be the truth, but I think you will gain more by letting
the readers form their own opinions from the mere facts.
- despite that, you seem to need to compare the products; I'm not sure
if just advertising and documenting the feature of IBO *WRT InterBase,
not in comparison with IBX* would be better.

In addition, it seems that no-one that knows well IBX cares to enter in
the field of this kind of comparisons. The gut feeling is that IBX is
Jeff Overcash and Jeff Overcash is IBX. In this situation, a comparison
is pointless: I'd just tell the world what goodies IBO has to offer, and
forget always taking IBX into the picture just to present it as the
unfortunate son...

> 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 am not qualified to comment on this.

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

I have said earlier that I don't think this is the wisest policy to
adopt, but I still wish that IBO will get the diffusion it deserves.
I'll keep my wishes about IBX for another place. ;-)
Finally, let me make clear once again that I'm here just to help (just
in case one misunderstands my thoughts once they're laid out in a
language which is not my own).
Regards.
--
____
_/\/ando