>=20 >=20 The responses I am getting here tend to make me believe no one has attempted to go the pure OOP way in designing classes that model the business. The answers reflect much opinion that it is not wise to go pure OOP because FoxPro is a relational database, but I think the data model and object model are two separate things here. If the object model is designed properly, the object model itself calls on the data environment which contains a portion of tables and relationships, I know it=92s not this simple. It is this data environment that contains some tables in the data model which is a separate model altogether.=20 If I understand you correctly here, what you are saying is that if an object is persistent, it is somehow it's own responsibility to 'save' itself and whether this is in an OODBMS or a RDBMS is irrelevant from the object model's point of view. =20 But on a theoretical level (and forgetting for a moment the technicallities and more specifically the 'payabilities') is there not a problem 'save' inheritance (like AKO relationships) in a RDBMS? Let's take the Policy object for example. It contains a Claims part and Premium part. All this contains mechanism that is common to all the policies and could be implemented as an abstract types. Then you could derive broad sectors of insurancy types like car insurance, health insurance etc. And then maybe each individual policy has its own addenda and special conditions that cannot be translated into properties (data) only, but would require methods that overwrite default behaviour as well. If that is your mission, I understand why you insist on an OOA/D approach. What I do not see is how you are going to 'save' the information contained in each of the individual policy contracts in my example in RDBMS. The closest that I have seen of an OODBMS in VFP is the .VCX where the methods are saved as Memo's and linked in at run time. And even this suffers from limitations, because these vcx's are neither tables nor objects, don't you think? What I am getting at is that as long as you do not somehow solve this problem, you'd better limit your requirement specifications to what can be implemetented in RDBMS, albeit less extensive in scope. To say it in J. Luis/Arnon controversy terms, subtyping is possible in the relational database sense, but inheritance is a broader concept, first because it involves processes (methods) and secondly because it involves overwriting these methods, which is not contained directly in subtyping. Makes sense? Marc. Regards, Marc