[fpc-devel] TClientDataset (was: Dnamic packages support)

[Michael Van Canneyt]

On Mon, 5 Nov 2007, Joost van der Sluis wrote:

> > Why ? 
> > Because we make use of it in 3200 places, and recoding this is
> > not an option :-)
> 
> Ok, then there's the question: Do we want to provide the ability to use
> existing DB-code with fpc?
> 
> It's a serious question, because if decide to do so, that will cost
> resources which could be otherwise used for something else.
> (Implementing a better db-model? Is the Delphi-model perfect?)

I think that the DB model of Delphi is very OK, but can use some extensions.
for instance TBufDataset can have a property Records[I : Integer] which
could give direct indexed access to all records in the dataset (as, I
understood, .NET does). This need not conflict with the current implementation.

What concerns the possibilities of N-Tier, I have the same opinion.
The ideas of Borland are OK, but the implementation can use some
improvements. DataAbstract of Remobjects springs to mind.
(although that one as well can use some improvements...)

> > 
> > If I would start from zero, I would not have problems with setting up the
> > whole thing to something like you describe. The main problem is that there 
> > is almost 10 years of code which should work as-is, as much as possible.
> > Since we heavily rely on almost all aspects of TClientDataset/TProvider 
> > stuff, that means we need it almost 100% equivalently...
> > 
> > We could try to compile Borlands' VCL code with FPC, of course, but then
> > there is the problem that the midas library is a black box, available only
> > for windows i386, which kind of defeats the purpose of the whole exercise..
> 
> I think I understand your point of view now. At first I thought that
> TBufDataset wouldn't be needed if we make a TClientDataset. But if you
> want to use a property to switch unidirectional on and off, it makes
> sense.

Great, understanding is already half the path :-)

What concerns the exact details of implementation, well, there we'll have to
see. I can live with a small change in API (getting rid of variants, for
one), as long as the global mechanism and idea is there.

Maybe we should get together once, and sit around the drawing board...

Michael.