(Note: this message is in reply to Eds message. For some reason my reply button is not working.)

The bug I noted is a bug. It is not the documented behavior with pointers in set relation.

If I am in table A and say "SET RELATION TO fkey INTO B" then A is the primary table and B is the secondary table.

I am not in the primary table. I'm in the target table. When you are in the target of a relation you can move your pointer back and forth as much as you want. You will then have to relect the primary alias and move the pointer in the primary table to reset the relation.

The bug I am documenting is that when I select the the target table, append a record, update the field on which the active index of the target table is built and reselect the primary table, moving the pointer in the primary table does not re-establish the relationship (at least not under the particular conditions I've described -- both aliases are optimistic table buffered updateable views which may well make a difference. ) In order to for the relationship to be re-establishable (not re-established, but able to be re-established) I have to move the pointer not in the PRIMARY table but in the TARGET table. THEN, and only then, selecting the primary alias and moving the pointer re-establishes the relationship. This is not way MicroSoft says it is supposed to behave, and is definitely a bug.

I thank you for trying to help and for all the help you have given myself and others in other instances. This particular case is anomalous behavior, but with a fairly simple workaround, and thus may be useful for others on this thread to know -- and is presented for that reason.

Thanks