At 09:17 PM 29/10/2004 +1000, you wrote:

> > SELECT FIELD1, FIELD2, FIELD3 FROM LOAN_S_ALL(:FIELD3)
> > KeyLinks property set to 'FIELD1'
> > and the MasterParamLinks set to 'FIELD3=Mast.FIELD3'
> > where "Mast" is the name of the table that has FIELD3 either as
> > its primary
> > key or as another unique key.
> >
> > Helen
>
>I'm still a bit confused though - you say at first there can't be a where
>clause. but now you say FIELD1 can be the keylinks.

You said FIELD1 was the KeyLink, i.e. some unique key in the output set.

>Now - in this case FIELD1 is definitely a PK of the underlying table source.

There is no "underlying table source" when the set comes from a SSP. But
the SSP has to be designed so that the output set is a virtual unique key

>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