AARGH! I should've read the messages in the right order. I didn't realize
tdataset had a recordcount. Sorry!

> First of all, I cannot remove it because it is built into the TDataset

base

> class. I am forced to implement something for it.

Point taken. I suggest recordcount then returning a true recordcount as a
default (if a query is created inside the program, or if a query is just
plugged into the datamodule). That would be best for people converting
projects to IBO, as the code written at that time expected a "reliable"
recordcount.

I agree with the rest of Your post. What You have to do (and we all have to
do) is to have a *backwards compatible* and *reliable* recordcount, but at
the same time introduce new ones, and avoid the old one at all cost, bc it
is slow, and it is easy to do real bad programming when using it.

Very much appreciated that You've looked so hard into things. Personally i
allways get dizzy when i look at the vcl database sourcecode.

> I will make TIBOQuery and TIBOTable do just what the BDE did (even though

I

> prefer otherwise) and then I will document that it is possible to use the
> way that I prefer things and explain the full ramifications of doing it.
> Which are, if you say IsSequenced is true then the RecordCount property

will

> deliver the quick report by looking at the buffers and if IsSequenced is
> false then RecordCount will do the full blown record count as it does with
> TQuery (only I will use a more efficient way).


> How does this sound? Is it clear enough to understand? How will this

affect

> InfoPower and other 3rd party tools?

I'm getting dizzy!

If we are stuck with a recordcount inherited from the tdataset, we better
make it return the correct values:-).

What about the ibo queries and datasets? Is it feasible to let them not have
a recordcount property? I would like them to have one, that is reliable, but
it should not be called recordcount. As per your description above, i will
never for sure know if a call to recordcount in a piece of code is getting
the intended recordcount unless i find out what the dataset properties is,
and what type the dataset is. I don't like that, but i see we're stuck with
recordcount in the tdataset derived components. I suggest you get rid of any
abiguity with your own objects and create two different methods - one fast
and unreliable, and one slow and reliable. (i only need the slow one, btw.
But maby others need the fast one for other purposes).

Tdataset deriatives : recordcount returns same number as the BDE - but
this can be changed programatically

ibo datasets : no recordcount function, but a recordcountserver that is
reliable & slow, and a recordcountclient that returns a fast but too low
number ;-)

Once more tnx for looking into the matter. I look forward to converting the
next 100.000+lines project to ibo in weeks to come. It will be easier than
this one!.


Dennis Fantoni