Sounds like you're missing the alias for the child table from the field names in the control source for child's textboxes.

>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