>The most widely used element in a business application is a customer table, therefore I will continue using the customer entity to ask my questions. 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’s not this simple. It is this data environment that contains some tables in the data model which is a separate model altogether. I think we can talk about an object model without even talking about a relational database, you could design your object model in C++, Delphi, VFP, etc.it doesn’t matter the database at this point. You only need to worry about this
>when the object model is well under control, the business functions are modeled, etc. Then at this point, design the data model based on the object model, because the object model will have eventually spelled out all of the business functions and entities. If any of you know where I am coming from, I will post more later. Thanks for all of the responses.

well, this is sort of what I am trying to say - if u've seen my lecture I talk there about an object model, and the data model derives right from it
taking your example of the customer table
I will have a customer object where the properties will eventually be fields

Arnon