[fpc-pascal] msedb and fcl-db benchmarks

Michael Van Canneyt michael.vancanneyt at wisa.be
Wed Jul 18 10:05:09 CEST 2007

On Wed, 18 Jul 2007, Martin Schreiber wrote:

> On Tuesday 17 July 2007 23.58, Joost van der Sluis wrote:
> > > So this makes your case, doesn't it. Martin argued that his dataset was
> > > designed to work together with his visual controls.
> >
> > Yes, but it's an important part, because exactly this is the part that
> > has changed. Except from this and the widestring-difference, there are
> > no real differences. So I'm very curious know why his dataset works
> > better with his visual controls.
> > I want to know this, so we can remove the need for two times the same
> > component. Or that's at least what I hope for.
> >
> What I need for the MSEgui components is 
> - fast RECNO access for the DB grid proportional scrollbar mode (I think we 
> talked about that when you changed TBufDataset to an linked list).
> - internal indexes to switch sorting order in DB grids fast.
> - calculated fields (which didn't work in TBufDataset at the time I needed 
> them).
> - internal calc fields (which are not implemented in TBufDataset up to now 
> - full BLOB and MEMO support (they where not fully functional in TSQLQuery at 
> the time I needed them).
> -"TClientDataset" functionality (not implemented in TBufDataset).
> - the storage of strings as widestrings to prevent converting from/to unicode 
> at every data access.
> - the storage of strings as pointer to a variable length string to allow the 
> MSEgui users to use long varchar fields without memory waste (TSQLQuery 
> stored the popular PostgreSQL TEXT field with dsMaxStringSize = 8192 bytes).
> - the limiting of the edited string length by character count and not byte 
> count (think on multibyte encodings or current Linux installations with utf-8 
> locals).
> - and possible more which comes into mind at the moment...

All this will not be a problem as this is why we'll merge the stuff in the
first place: To have 1 set of components with the most possibilities.
With the possible exception of the storage of strings as pointers. This is
an internal issue which you should not worry about. The TEXT field in
postgressql should be mapped to a blob field then.


More information about the fpc-pascal mailing list