>
>Although I HAVE seen some situations that were cyclical, the invoice<->client one isn't - it's merely bi-directional. Your client still has multiple invoices, each of which have multiple lines. You can look from a client to one or more invoices, or from any invoice to the specific client information (address, phone, etc.).
>
I think you look at this from the point of view of the database design then you are right. But my confusion comes from the design of the corresponding managing objects: In situations where you need to implement both directions at the same time, how do you manage _consistently_ who is the owner of who. How do you make sure that the access data from the tables do not get overwritten. How do you make you access to the methods consistent, so that you do not even have to look at the code to know and to be sure that everything will work.

The answer to this must lie in what they call patterns I guess. But this again requires a lot of "learning". It boils down to the famous granularity of the design of the classes. There is no theory about this, as far as I know, only very vague rules of thumb, especially in the area of information systems, that for OO gurus is the "dépassé" type of applications, that are way to simple to give any thought to.

Face it. Following OO rules blindly is not the panacea. Have you read the Accounting Pattern in Martin Fowlers "Analysis Patterns"? I think there is not much more here than some sophisticated rules (and confusing graphs) on how to design (mostly through normalization) a robust accounting system, but we have been doing _that_ for years or we would not be sitting here discussing these matters.

>I get confused when designing more than 2 many-to-many relationships linked together. Views/cursor get too involved in multiple outer joins.
>
Again, this is a problem of database design no?

>Some dayl Marc, you may convince me. Right now I still prefer an updateable view if I have to do data entry in a grid. Cursor- or table-driven grid refreshes with more than 2 appends are tricky. There's some non-standard behaviour which is NOT seen with views.

Ah! you _are_ reading everything eh! :). I do not append. I prepare an empty cursor with say 200 lines and submit that to the grid. The closest you can get to filling out a form on paper since the apparition (that is not English, is it) of the spreasheet. No strings. Let the user enter what ever he likes and validate his entries.

Another advantage, I think, is the fact that you can have fields that are not present in the database. I use lock and color a lot. The allow me to control the infamous dynamicX properties of the columns, without breaking my back on trying to set them from the screen designer.
>
>>
>>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 ...
>
>My $.02 US is that you need to look at the expected size/lifetime of the app. If it's never going to have more than 100 MB of data, use tables and let your users scroll the whole table. They aren't going to need C/S before the app and/or the computers die of old age. If you're starting with 2 GB of data (even if it's in multiple tables) start planning how to upgrade to C/S as part of the initial specs, even if the upgrade date is 2001.
>>
Here Barabara, let me be the progressive guy. C/S is not only about size of the DB, but also about communication, internet etc. So where possible, using OO to allow for C/S makes sense (to me).

>
>Tell him I said it was okay, that we need more information about this :-)
>
Well, Barbara, if he _will_ listen to anybody, I'm sure he will listen to you. You two have some common way of thinking referring to previous threads :).

Marc