Subject | Re: [IBO] Lookupcombobox question |
---|---|
Author | Helen Borrie |
Post date | 2001-07-06T15:26:34Z |
At 02:47 PM 06-07-01 +0000, you wrote:
Take out the lookup table identifier from the keylinks string.
And you won't need KeyDescLinks. That is used in the embedded lookupcombo when the description field has to be updated as a result of the parent dataset being scrolled. The normal purpose of lookup keys is to provide a key that points to a matching primary key in the lookup dataset. By redundantly storing the model name in the parent dataset, the parent has no need to search for an updated description.
The downside to this approach is that, if the model name changes in the underlying lookup table, the value stored in the table will no longer be valid. Even just correcting a typo in the Model table will render all lookup refs to that record invalid. It is much sounder RDBMS practice to normalise out such redundancies and use genuine atomic keys for relationships.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>GeoffAlmost...
>
>I have been using IBO for a while and I am able to get the
>lookupcombo to work when the "lookup dataset" has two fields: a key
>field and a description field. Then I have no problems. The problem
>here is that the "lookup dataset" has only one field and this is the
>field that must go to the "master database". I also want to display
>the field in the "master database" in a grid as well. I have tried
>your enhanced lookupcombo as well, but I am sure my problem is in the
>keylinks property. My Keylinks and KeyDescLinks looks like this:
>
>MODELS.MODELNAME=STOCK.MODEL
>
>Is this correct ?
Take out the lookup table identifier from the keylinks string.
And you won't need KeyDescLinks. That is used in the embedded lookupcombo when the description field has to be updated as a result of the parent dataset being scrolled. The normal purpose of lookup keys is to provide a key that points to a matching primary key in the lookup dataset. By redundantly storing the model name in the parent dataset, the parent has no need to search for an updated description.
The downside to this approach is that, if the model name changes in the underlying lookup table, the value stored in the table will no longer be valid. Even just correcting a typo in the Model table will render all lookup refs to that record invalid. It is much sounder RDBMS practice to normalise out such redundancies and use genuine atomic keys for relationships.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________