>
>>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.
>
For the Client object you are probably right, but the real advantage of OO comes when you "take off" from you database schema. Take for example the invoice object, that is comprised of a header and lines (typically). What I have not figured out to this date is how I deal with the following: Invoices are related to clients, so an invoice could "have" a client, be it only to enforce business rules, but on the other hand, the client (or his account) is composed of invoice lines. Here it the client who owns invoice. This cyclicity is something I stilltstill have to master, not conceptuallly, by from the point of view of the design.

Steve, I told you I was confused .... :)


>>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.

Imagine: oInvoice.Client.Telephonenr. For me, these kinds of constructionsare dreams come true.

>>
>-> 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.
>
I guess I have a personal thing against views... and my use of cursors dates back from the FPD days. Once you are used to those temporary files it is hard to let go, even admittedly if they are time savers in certain circumstances.

... and nothing beats an empty cursor when it comes to do data entry in grids. Some day, Barbara, some day I will be able to prove my point here :).

>
>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.

Yes, I too am preparing for C/S, but I was shocked to experience the differecne in speed between seek and sql for one record accesses. It may seem irrelevant, who's going to know the difference between 0.1 and 0.4 second, but multiply this with 2 or 300 and believe me, it makes you think twice ...

On the whole, I think that all this tinkering takes a lot of developing time and I hope that my boss is not reading this, but I will persevere because I experienced a definite improvement in robustness and maintenability on my systems in production. Working as we do now is more difficult from the debugging point of view. It is interesting that this concept has lost a lot of its interest lately. It used to be the number 1 concern in the days when structured programming was the hot topic.

But enough for now, or this thread will become unbearable to Michel.

Kind regards,

Marc.

>
>Steve