Lets say I have an orders and customer class. Essentially, these classes are wrappers for ADO recordsets. If I wish to delete, update, create new data, I would probably have a another class soley devoted to that task. That class would be a wrapper for the ADO command object. So, if I wanted to save my customer class, I would pass the customer class instance to the save method of my data object.



>>As far as OOP goes, when it comes to middle-tier development, VB and VFP are >essentially the same level. Why? Because inhertiance plays little or no role >in middle-tier work. As far as a flexible cursor engine goes, yes, that is an >advantage of VFP. However, I don't think you can really demo that in 15 minutes.
>
>I don't think so. In VFP you can create a custom business object class that has standard methods defined and standard behavior defined in those methods. In VB, you have to create this for each business object. I think not having to hand code each Insert, Update, Delete, retrieval of a list of records, etc. is a pretty big advantage that you get from OOP. But, could you do this in VB by creating a base business object in a DLL that handled this kind of thing?