> >3. where I need some assistance...
> >I have a LookupCombo which has two fields which get assigned to
> the query it
> >is linked to. One field is an integer, the other is a Float.
> >Now when I refresh this query I ocasionally get Unknown Cursor.
> >As I understand it, the Keylinks definition is being used to
> assign a value
> >from the source into the link query, and it is also being used
> to locate the
> >record in the lookup.
>
> This is incorrect use of the KeySource-Lookup relationship. The
> unique key
> on the Lookup side can point to one and only one column on the KeySource
> side. This is really the same situation you describe in 1. The
> KeySource
> dataset actually polls the lookup keys each time you scroll it (the
> KeySource).
>
> >Question: Is there any way I can make this arrangement use only
> one of the
> >keylinks to do the lookup, but use both to do the assignment?
>
> Well, you could do that somehow...but it begs the question of
> normalisation
> if you have the same pair of values stored uniquely in two places.
>
> If the situation is really that the lookup dataset provides a
> pair of keys,
> rather than *two* keys, then that's simpler and not so severely redundant
> (as long as the table supplying the pair isn't subject to change!!). In
> that case, you have one KeyLink which comprises two columns, i.e. a
> compound key. You'll have the two columns listed in KeyLinks and
> KeyDescLinks.
>
> What you need to do is figure out which situation you have. If
> the pairing
> is volatile, then you have two different keys and you need two lookups on
> the same table. You can use the current value of one key to filter the
> lookup for the other , so that lkcombo B only shows the values that can
> occur with the current value in lkcombo A.
>
> Helen

I don't have two keys, I suppose I was using the keylinks for what now looks
like a handy side effect. I was using the one key to do the lookup and
assignment but by putting another keylink in, I was getting the pleasant
additional effect of assigning the ItemRate of the lookup query into the
source query ItemRate field. It's just that the lookup task was occasionally
throwing an exception - I imagine because a float is not euqal to a float
(occasionally).
I will investigate your recommended way of assigning this rate field and not
take my "shortcut" - I thought it was a nice feature.. :-) pity.
Thanks for your comments
Alan