Arnon, thanks for your response. > > > If I understand u correctly then what u are suggesting here is a limited > version of such a wrapper object - how for example u would drop this object on a grid for viewing, remeber if u are taking the trouble to implemt it in complete OO way than it should act like an object > thus, it should handle all the I/O and interaction with the table > (or why bother in the first place) for starters > ur suggestions should actually be a container which will contain "Record Object" (rmember sumtimes u need more than one record at a time) > > so what u have is > a tableobject dealing with Open/close, seek/locate, Relations, buffering/updates containing "record objects" with the different fields > (IMHO it more OO if the tableobject deals with table buffering schemes and the recordobject with recordbuffering shemes) > and have all the other objects using these as "record source" It would make the rest of the application independent of the underlying DBMS. Is that not one of the requirements of OO? You could then build a second level objects that combine the table wrappers to the domain objects, following the three tier architecture. This would be where the 'reusable' classes like Customer would reside. >From a programming point of you gain in robustness what you lose in development speed: it makes sure that you never forget to set the right work area, order, data session, buffering scheme etc. I agree that it stands in the way of visual coding, but that is because VFP uses the table structure in its visual component. I think you said yourself that to be OO one should be able to tie objects to the GUI, no? So ... would you not agree that 'Visuality' stands somehow in the way of pure OO at this stage in VFP? > , this is btw, one of the reasons I use DEs as seperate object so I can have forms that uses more than one "table setup" > and naturally only the instantiations are data specific > I think this will only slow VFP without much gain Well from what I see, what I would do is not so different form DE, because what is a DE if it is not a combination of 'my' tableBase classes. Regards, Marc