>>
>>The confusion is quite understandable.
>
>What a nice thing to say. :)

-> I've done several different methods of doing this. I'm still just as confused. I'm comfortable with how I'm now doing it, but who knows, tomorrow I may find a different manner.
>

>You describe a wrapper object around a table here, do you not? I have found that I do not need them. I tend to use SCATTER NAME to a property of a "higher" info object. It gives you code that is really easy to read.
-> Pretty much it...... For the smaller ones, they are essentially the tables, but others are truly biz objects as they have the rules and also create their own views when necessary. They are responsible for retrieving or dealing with all data related to them. For example.....let's take a Client class definition I have in an app called Court. Yes, it's responsible for the data directly to the table called Client, but also retrieves or deals with other data related to the Client too.

>I thought that we should not be to tied by the structures tables (but then I am the one who's confuse here :)).
-> That's probably a really good point here. I've just not quite come up with an acceptable solution to me on how to avoid that. Yes, SCATTER NAME is something I should check out.....I must admit that I haven't yet. For now, what I have is working.
>
>Interesting, but what about grids. I tend to "clone" my tables and bind the forms to those clones. The clones are the glue between my forms, that I try (like you I think) to keep as light as I can, I hate the screen designer.
-> Grids are typically filled by views. These views of related data would be created by something like the "Client" class described above which is also responsible for related data.

>Thanks,
>
>Marc

Now you see why I indicated in my first response that I don't advocate this method as a cure all to anyone. I'm also interested in how others here are doing this. I do use an occassional SEEK, but for the most part, everything is SQL statements. I prefer INSERT/UPDATE/DELETE using the class properties so my
forms control sources are bound to the class properties rather than directly to any tables or views. I'm happy with what I've done and it's working but I certainly don't profess it to be the one and only.

Steve