> >A SELECT * FROM LOANS_S_ALL(:FK_SECCODE) WHERE FIELD1=1
> >would return one and only one record.
>
> That's good. Then FIELD1 is the right choice for the KeyLink.
>
> >But does IBO try to refresh the one buffer record with this SQL?
>
> Well, it would, if it was refreshing a cursor. But there is no
> cursor. So, to "refresh" the buffer from a SSP, it has to run the SSP
> again, i.e. it will use the MasterParamLinks again.
>
> The KeyLinks matters in two ways:
> 1) it makes each row in the buffer unique. IBO needs this to
> make the set
> scrollable.
> 2) if you are picking up values from the *output* of the SP, in order to
> kick off an executable procedure that you are calling in an XxxSQL
> property, then the keylinks are needed as values for the input parameters
> to those procedures. Hence, if you want this virtual detail set to be
> updatable, the fact that FIELD1 is unique might not be enough, if your
> XxxxSQL statements need other keys.
>
> Helen
>

this all sounds fine.
Do you know what difference it would make to IBO to have
FIELD1=FIELD1
as opposed to
FIELD1=Mast.FIELD1
?
The former works fine operationally. It does not always throw a cursor
unknow error. Only when trying to close the application.
Maybe something in IBO is firing when the application is closing but before
the query has closed.
Alan