>Hi Arnon,
>
>Could you not a kind of tableBase class that handles Opening, Closing,
>Seeking, Locking etc. and then code generate for each table of the
>database a class that would contain a property for each field (using
>afields). Would that be the wrapper object you are talking about.
>

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"

what I do instead is have every object "independednt" in the sense that it takes care of both the actions and the data it might have
, 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

btw, VFP has limited implementation of treating data as objects in the form of the DBC (that holds several tables properties+RI/trigger code), use of DEs and even command like SCATTER .. NAME objname that gives u an object where the properties are the fields
etc.