At 08:57 PM 6/06/2004 +1000, Alan McDonald wrote:

>In fact I have, now, 3 places where I can get unknown cursor exceptions.
>1. see previous post where KeyLinksAutoDefine is True when it should be
>False for Lookup Combos.

This really wouldn't happen, since KeyLinksAutodefine doesn't override
user-entered KeyLinks - including those that you enter for lookup keys. It
won't do any harm to set it false but it's not an issue when Lookup
Keylinks are used properly (so, see my comments on 3, below)

>2. Where I need to have an action which deletes a record currently in view
>via another connection and transaction. When I try to refresh the current
>view, I understandably get unknown cursor since the grid is trying to fetch
>a row which now no longer exists. Easy fixed by forcing a Close and Open on
>the Query.

In fact, a Refresh of an IB_Query or IBOQuery is a Close and
Open. However, where you might get this error on a since-deleted row is
where the RefreshAction is raKeepDataPos, if the deleted row happens to be
in your buffer, you have PessimisticLocking True and you request to edit
the deleted row. What could help is to use BufferSynchroFlags - at least
[bsBeforeEdit].

>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