--- In IBObjects@yahoogroups.com, Geoff Worboys <geoff@...> wrote:

>
> > I went thru the walkthru by Lars George, in fact that was
> > before I posted this question. Just a quick mention that
> > the walkthru talks about Property KeyLinks
> > (PRODUCETYPE.TYPE=PRODUCE.TYPE) but if you login as the
> > owner of PRODUCETYPE then you have to say TYPE=PRODUCE.TYPE
> > on the keylinks property otherwise it refuses to work. Very
> > frustrating to debug this. This is why I say it is not
> > intuitive - if PROD owns PRODUCETYPE and PRODUCE then why
> > can't you always use the "Schema <dot>" in front of the table?
>
> I do not understand what this is about... but then I never have
> tables owned by different users. You cannot expect a lookup to
> work unless the user has sufficient access to both tables
> involved in the relationship, other than that the table.field
> notation has always worked for me (there could be alias issues
> with FBv2, which I imagine means using alias.field).
>
> As for "schema <dot>" this notation does not (yet) work for any
> Firebird database. It has been discussed in the architect list
> but AFAIK there has been no progress on that front.
>
>
> > Anyway, using this walkthrough, I still cannot do what I want
> > this IB_LookupCombo to do. It should be the easiest thing to
> > put two fields into the display of the IB_LookupCombo but no
> > matter what I do, the second field refuses to display. It
> > displays only in the popup of the IB_LookupCombo. I hope
> > someone can understand this dilemma otherwise I will have to
> > write my own lookup component which kind of defeats the
> > purpose of using IB Objects.
>
> IB_LookupCombo behaves like a ComboBox in csDropDown style,
> where it is possible to type into the display/text area. Such
> typing allows the incremental search/lookup feature - type
> "Wor" to jump all the way down, past perhaps thousands of rows,
> to the words starting with "Wor". However such typing also
> means there are limits on how you can use the display area, for
> example arbitrary splitting into columns for additional field
> display would not be practical (given the Windows API).
>
> Note however that there are two ways of showing the additional
> field from the lookup - NOT in the ib_lookupcombo, but in a
> separate control.
>
> . connect a TIB_Edit or TIB_Text to lookup datasource/fields
> Simple enough, you will almost certainly want to make
> the lookup dataset read-only to prevent it accidently
> going into edit mode, probably set TabStop to false on
> the TIB_Edit if you dont want ti part of the edit seq.
>
> . use a join in the main dataset and the KeyDescLinks in
> the lookup dataset. This is just like using KeyDescLinks
> for the name/lookup field but you use it for additional
> fields. You need a join rather than a subselect in the
> main dataset for efficiency, but that also means defining
> the main dataset KeyRelation and so on.
>
>
> There is yet another way in which you may want to use multiple
> fields in a lookup. Given the table of Australian suburbs and
> postcodes:
> SUBURB
> PK
> NAME
> POSTCODE
> STATE
>
> I found it necessary to create the unique lookup index on both
> the NAME and POSTCODE fields (as the same suburb-name may
> appear in different postcodes, and some suburb-names have the
> same postcode).
>
> To achieve this with TIB_LookupCombo it would be necessary to
> create a duplicate field (whether it needs to be a real field
> or only a computed field depends on various factors, note that
> new versions of Firebird support expression indexes - see the
> FB v2 release notes - but I have not used that to know how well
> it works in this situation). eg:
> LOOKUP_NAME COMPUTED BY (NAME || ', ' || POSTCODE)
>
> Now it is possible to use LOOKUP_NAME instead of NAME and so
> have two columns inside the display (albeit using the ','
> delimiter rather than a column like display).
>
> My own lookup control variation:
> http://www.telesiscomputing.com.au/enhcomp.htm
> has special support for the above scenario but may be redundant
> now that Firebird has expression indexes.
>
>
> If none of the above suggests help then feel free to go ahead
> and write your own. I wont bother to wish you luck, the ONLY
> way to get a lookup working is with LOTS of hard work.
>
> --
> Geoff Worboys
> Telesis Computing
>

Thanks for all the very useful commentary and suggestions. Your
suggestion of a TIB_Text certainly works; I have already used that
in combination with another lookup, but this was for fields in
different tables joined by foreign key, linked to yet another
foreigk key relationship to the parent form. I guess I will stick to
the TIB_Text method, although it is not the most elegant looking.

Apologies for my typo above. I actually didn't mean to use the
word "schema", I actually meant "Table <dot>" which actually doesn't
work if I login as the owner of the table, it only works if I login
as sysdba, which is strange. However, the schema <dot> notation
would be nice as well, seeing that FB is moving towards the ANSI
standards that Oracle subscribe to :) Now if only the guys at Quest
could support FB2, I would be deliriously happy :)

Thanks a lot for the feedback, Helen and Geoff.
Regards
Shanil