--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> At 08:52 AM 30/03/2003 +0000, you wrote:
>
> >Never happened to you to have similar needs?
>
> No, never. I wouldn't design the relations this way. IBO works

properly

> with my schema designs, that's why I like it so much.
>
> Now I can't tell whether you want advice on changing the metadata

design to

> make it work logically the way it needs to...or whether you

seriously think

> IBO should somehow provide the means to make a wrong design work.
>
> From your two postings I see that you aren't getting to grips with the
> difference between K/L and M/D. I could possibly help a little more

with

> this if you could explain *what* you think you need a K/L

relationship to

> do here...
>
> Helen

I thought it was clear from my first posting, but after your message
I've rethinked about that.
Well, forget the master-detail.
I've the B table with fiscal_year + Code. Code is unique inside the
same fiscal_year, since it's used in tables where the relation must be
made inside the same fiscal year, so A table has a fiscal_year, and B
table has a fiscal_year.
This is because I can't have a separate database for each fiscal year,
so I have to add fiscal year to all tables that have historical needs.
When I want to work inside a certain (user selected) fiscal year, I've
a parameter in my queries that restricts the dataset returned so I get
only records related to the choosen fiscal year.
The problem arises since the K/L uses "Keylinks" with a double meaning:
a) to tell the query what is the unique key to retrieve one record
b) to tell the query what fields have to be copied in the "source" (A)
table.

the flaw in my design is that, since the fiscal_year is the same for A
table and for B table, I store in the A table only the CODE of the B
table.
It worked until an user pressed Canc to remove the lookup relation,
and doing so Code + Fiscal_year were removed from A table, but A table
needs that field!

I could:
a) store B code and B fiscal year in A table
b) change IBO understanding of Keylinks so the syntax
B.FISCAL_YEAR
B.CODE=A.LKP_CODE
will work with double meaning, as explained in a previous message.

before your message, I thought that b) was the right way to go, after
your message I've discovered my design flaw so I don't know if b)
would be an interesting improvements for such situations or just an
abnormal one.
So I think I will re-think my design.
thanks for your invaluable suggestions
regards
Marco Menardi