[fpc-pascal] Master Detail relationship in SQLdb

Joost van der Sluis joost at cnoc.nl
Sun Jul 15 12:03:49 CEST 2007


On Sun, 2007-07-15 at 07:24 +0200, Martin Schreiber wrote:
> On Sunday 15 July 2007 01.10, Joost van der Sluis wrote:

> > I have a question about the widestrings. I thought that tmsebufdataset
> > handles all strings as widestrings. But I can't find any reference to
> > that in the code. It would be silly anyways: from the db-engine you'll
> > get 8-bytes based strings. And a ftString fields's .asString method will
> > return a normal ansistring. The same holds for your code.
> >
> I needed to use my own TField descendants because I can not modify db.pp . See 
> lib/common/msedb.pas, especially tmsestringfield, TField.GetClassDesc does 
> not workfor them BTW.

It's very difficult to see what you do in msedb.pas. That's because it's
(guess) about 80% fpc code. But then renamed and refactored. With some
minor changes. And a few additions, offcourse. But it's diffucult to see
what you really do, without digging in the code for hours.

> The strings are converted from utf8 or current locale encoding to UCS2 after 
> fetching the data from database and to utf8 or current locale encoding before 
> sending data to the database in order the string encoding needs not to be 
> converted while displaying and editing data in MSEgui.

Ok, but a normal 'select * from table' generates a TDataset with regular
TStringFields. And then no concersion takes place? Only if you
specificly decide to use TMseStringField?

Thus if we add a poperty to a TSQLQuery to map all strings to a
ftWideString. And then add a conversion-option so that the strings are
converted when they are fetched you're done. And you can remove your
bufdataset and a lot of other code-duplication? 

> I can say that this concept and the whole MSEide+MSEgui system turned out to 
> be very successful in commercial database applications.

And it could be even better, of we cooperate more, and stop duplicating
code. I've seen already a few bugs in your code, which are already
solved in fpc. And the other way around. That's madness. So I want to
find out what it is that you really need... See if we can implement that
in the db-unit. That could be of use for others also.


Joost.




More information about the fpc-pascal mailing list