You know, Hilmar, I noticed a behavior happening when I would open up BROWSE windows to see if the RELATION was going the way I wanted it to. When I would click from one browse to the other, the right data would then appear in each CHILD table's browse window, as I moved down through the Parent table. So, it hit me just a few minutes ago that what I was doing was SELECTing the PARENT table then the CHILD table, so I added two lines of code to the code below, which has made all the difference in the world. It now works as it should.

I discovered that the record pointer was indeed moving in the child table, due to the SET RELATION, but on the form the textbox's display value did not change. I thought that REFRESH should take care of this but it didn't. So, this must need a little push to get the data to display. WHY not select the child table, then get the focus back to the PARENT?

By the way, how does everyone put their code into a white background on this forum?

LPARAMETERS nColIndex
Local lcMessage, lnResponse

WITH ThisForm
IF .IsChanged()
lcMessage = "Do you want to save your changes before proceeding?"
lnResponse = MESSAGEBOX(lcMessage, 4 + 32, "Save changes?")
IF lnResponse = 6 && Yes (7=No)
.cmdSave.Click() && Clicks the SAVE command button.
ELSE
.Revert()
.cmdSave.Enabled = .F.
ENDIF
ENDIF
.IsDeleted()
*** TWO NEW LINES OF CODE FIXED THE PROBLEM.
*** The PARENT tbale is already selected, so select
*** the CHILD table then go back to the PARENT. This
*** causes the data to display properly, rather than
*** appearing to have the child record stuck where it
*** orginated from.
SELECT POBYRFIL
SELECT (.cTable)
***
.CountRecs()
ENDWITH