[fpc-devel] TDataset.ClearBuffers change in svn revision 3138

Joost van der Sluis joost at cnoc.nl
Wed Apr 5 12:15:19 CEST 2006


On Mon, 2006-04-03 at 21:29 -0300, Luiz Americo Pereira Camara wrote:
> In revision 3138 TDataset.Clearbuffers call InternalInitRecord to empty 
> the ActiveBuffer. I have two comments:

> - In DoInsertAppend InternalInitRecord will be called twice: one through 
> ClearBuffers and other through InitRecord

Yes, but twice for very different records, and only if it's an append.
That's because 'append' effectively does a 'last' and then 'insert'.
That it's called for the insert is logical. For the 'last'-part, see
below:

> - ClearBuffers is called in First, Last, Resync: in this situations is 
> desired to clear the ActiveBuffer?

It is in the case of Resync. If a 'fuzzy resync' occurs that is most
often because that the dataset is empty all of a sudden. For example if
the last record is deleted. Or, for sqldb, if there are records added to
a empty dataset, and cancelupdates is called.
If InternalInitRecord isn't called then, you will still see the data of
the latest record before the dataset became empty. If that record isn't
cleared with InternalInitRecord, it will look like if there is still
data. (although IsEmpty is true)

So I've first added InternalInitRecord to Resync, but then I saw
ClearBuffers and found it more logical to do it there. Since
ClearBuffers clears the buffers if the dataset gets empty.

Only I haven't thought about it that First and Last also calls it. On
the other hand, if one does a 'first' and the dataset seems to be empty,
the active record should be cleared. But I think you'll never encounter
this problem, since the dataset most probably already was empty before
the 'last' or 'first' calls...

So, I think calling it in ClearBuffers is more logical, doing it in
resync is somewhat better for performance?

Joost.




More information about the fpc-devel mailing list