On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote: > On Mon, 16 Jul 2012, Martin Schreiber wrote: > > On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote: > >> Well, from your code adding the following to the protected section: > >> > >> Property ValueBuffer : Pointer Read FValueBuffer; > >> Property Validating : Boolean Read FValidating ; > >> > >> Should be enough to remove the need for the TFieldCracker ? > > > > Unfortunately no: > > " > > procedure tmsebufdataset.checkfreebuffer(const afield: tfield); > > begin > > {$ifdef FPC}{$warnings off}{$endif} > > with tfieldcracker(afield) do begin > > {$ifdef FPC}{$warnings on}{$endif} > > if foffset and 2 <> 0 then begin > > freemem(fvaluebuffer); > > fvaluebuffer:= nil; > > end; > > end; > > end; > > " > > If I understand correctly, you have in the record buffer just the pointer > of the (wide)string instead of the actual string data ? > Correct. The UnicodeString pointer. That has not directly to do with the procedure above BTW. This one is to allow changing field values in OnValidate IIRC.
> If so, why then didn't you implement the string fields as blobs are > implemented in SQLDB (it is basically the same problem), in that case you > would not need the internal fields of TField at all ? > Maybe, but what about performance? Another complication is the "updatebuffer" with the "oldvalues". > If that is not possible, it means you need a mechanism to 'finalize' the > record buffer whenever it is re-filled or goes out of scope ? > That mechanism is implemented in tmsebufdataset and does not need tfieldcracker IIRC. tmsebufdatset holds a list of record offsets which must be finalized. Thanks, Martin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel