>1) If you add a record to a view with an active index involved as target in a set relation, the index apparently does not refresh right away. By using the GOTO command to goto the record which has just been added (and which the recno() function will show as the current record) an update to the index is forced.
>
>The following is simplified code to append a record to two related views v_juvm_relations, and v_juvm_juv_rela. V_juvm_juv_rela is indexed and is the target of the relation. v_juvm_relations is the primary alias
>
>Code:
>

>DODEFAULT()
>LOCAL  ln_juv_rela_rec && define local numeric var to store recno
>SELECT v_juvm_relations &&  Select the primary alias
>APPEND BLANK  && add a blank record
>SELECT v_juvm_juv_rela && Select the secondary indexed target alias
>APPEND BLANK && add a record
>ln_juv_rela_rec=RECNO() && store the record numbers
>
>*Update the foreign keys, including rela_key the active index used
>* for the relation
>REPL juv_key WITH  v_juvm_juveniles.juv_key,;
>     rela_key WITH v_juvm_relations.rela_key
>
>*The following code is to force the index to see the new record
>*I could use GO RECNO() instead of the recno in a variable, but
>*I think the variable is easier to follow. Note that the relation
>*will fail if the following line is removed
>
>GO ln_juv_rela_rec && needed to refresh v_juvm_juv_rela cursor

This is documented behavior;  the relation won't take effect until you've moved the record pointer (even a GO 0 will work) to allow you to make a bunch of changes and not get slammed back to the relation default positions.  If the aliases are buffered, the indexes won't be updated until the buffered data is committed to the underlying tables via TABLEUPDATE() (or with ow buffering, the implied TABLEUPDATE() that occurs when the record pointer is moved.)

>
>SELECT v_juvm_relations && Select the primary alias
>THISFORM.pgfbizobj.page6.grd_codebook_grid1.REFRESH() && Refresh grid
>