Dennis,

Too late to change the native IBO stuff. RecordCount is accurate there as it
really should be. I just had to make it inaccurate because the TDBGrid
control directly referenced it and that would have resulted in awful things.
I have made all IBO native controls NOT use RecordCount in any way.

RecordCount is *VERY* useful when working with native IBO and I rely on it
heavily. RecordCount *is* accurate for the given slice in time and
transaction that it is running in. I will not remove it from IBO.

If you want the "inaccurate" record count that I conjured up for TDataset,
just make use of the standard properties in native IBO classes called:

BufferRowCount - tells how many rows are fetched into the buffer.
BufferHasEof - tells if all the records to the end direction are fetched
into the buffer.
BufferHasBof - tells if all records in the backwards direction are fetched
into the buffer. This won't actually matter until v4 where I will have the
buffer windowing. For now this always returns true.

and put something together...

Here's my code:

function TIBODataset.GetRecordCount: longint;
begin
Result := 0;
if Active then
begin
if IsSequenced then
begin
if not InternalDataset.BufferHasEof and
( InternalDataset.BufferRowCount < 2 ) then
InternalDataset.ValidateRows( 1, 2 ); // make sure to detect single
row only.
Result := InternalDataset.BufferRowCount;
if not InternalDataset.BufferHasBof or
not InternalDataset.BufferHasEof then
Inc( Result, BufferCount div 2 + 1 );
end
else
Result := RecordCountQuery;
end;
end;

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

----- Original Message -----
From: "Dennis Fantoni" <df@...>
To: <IBObjects@egroups.com>
Sent: Saturday, December 02, 2000 7:51 AM
Subject: Re: [IBO] RecordCount (for IBO v4) (or sooner if you like)


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