Yes the m I am sending is for memory variable and when you study it in depth I have made it work in such a case as in FPD there is no buffering only memory vars. The save and restore is for the child table and I have confirmed that there are no filters at the time of seekchild() execution.

But generally this is working, just this one case.

>>Hi all
>>
>>I know this may sound repeating, but it happended. The following code failed only one single time and even LOCATE could not give the right results. I have tried recreating index but failed.
>>
>>

>>IF seekchild("m", "a09ssale")
>>	SCAN WHILE relatedchild("m", "a09ssale")
>>...etc...
>>

>>
>>The following are the codes in my framework. They work regularly but failed once and wont correct itself. The problem being that say out of 10 children records the following code in this special case starts with the second record always of the 10. Even locate gave me the same result, located the 2nd record. When I view these 10 records in the browse window all 10 of them show. In solution I changed the above SCAN WHILE to SCAN FOR and this one record started getting involved again. Any advise what I might have done wrong, which happens only once that even locate could not salvage?
>>
>>

>>*!*****************************************************************************
>>*!
>>*!       Function: SEEKCHILD
>>*!
>>*!      Called by: UNREGISTERED()     (function in VSO.PRG)
>>*!
>>*!*****************************************************************************
>>FUNCTION seekchild
>>	
>>	*@**************************************************************************
>>	*@ EXTERNAL FUNCTION => seekchild()
>>	*@
>>	*@ Seeks the Parent DBF's Children in Children DBF using the UNIQUEID connection.
>>	*@
>>	*@*** Parameters
>>	*@ String -> Parent DBF's Name
>>	*@ String -> Child DBF's Name in which to SEEK Parent's Current Record
>>	*@
>>	*@*** Return Value
>>	*@ Logical -> .T. - SEEK Successful
>>	*@            .F. - SEEK Failed
>>	*@
>>	*@**************************************************************************
>>	
>>	*** History
>>	***
>>	*** 18/10/97 Created
>>	*** 13/05/99 store the tag name into m._vsoerror for reporting
>>	
>>	PARAMETERS m.zparent, m.zchild
>>	
>>	PRIVATE ALL LIKE z*
>>	
>>	m.zsavselect = SELECT()
>>	
>>	SELECT (m.zchild)
>>	m.zsavorder = ORDER()
>>	
>>	m._vsoerror = "docid"
>>	SET ORDER TO TAG docid
>>	
>>*-*	= _gotop()
>>*-*	
>>*-*	LOCATE FOR &zchild..docid = &zparent..uniqueid
>>*-*	
>>*-*	IF FOUND()
>>
>>	IF SEEK(&zparent..uniqueid)
>>		m.zretval = .T.
>>	ELSE
>>		m.zretval = .F.
>>	ENDIF
>>	
>>	m._vsoerror = m.zsavorder
>>	SET ORDER TO TAG (m.zsavorder)
>>	
>>	SELECT (m.zsavselect)
>>	
>>	RETURN m.zretval
>>	
>>*!*****************************************************************************
>>*!
>>*!       Function: RELATEDCHILD
>>*!
>>*!      Called by: UNREGISTERED()     (function in VSO.PRG)
>>*!
>>*!*****************************************************************************
>>FUNCTION relatedchild
>>	
>>	*@**************************************************************************
>>	*@ EXTERNAL FUNCTION => relatedchild()
>>	*@
>>	*@ Return Logical values depending on the current record ID of the Parent
>>	*@ DBF's match with the current record ID of the Child DBF.
>>	*@
>>	*@*** Parameters
>>	*@ String -> Parent DBF's Name
>>	*@ String -> Child DBF's Name with which to compare the Parent's
>>	*@           Current ID Value
>>	*@
>>	*@*** Return Value
>>	*@ Logical -> .T. - Match Successful
>>	*@            .F. - Match Failed
>>	*@
>>	*@**************************************************************************
>>	
>>	*** History
>>	***
>>	*** 08/11/97 Created
>>	
>>	PARAMETERS m.zparent, m.zchild
>>	
>>	PRIVATE ALL LIKE z*
>>	
>>	RETURN &zchild..docid = &zparent..uniqueid
>>

>
>Bhavbuti,
>I didn't check in depth but "m" is a parent table alias ??? "m" stands for memory variable. Thinking you might be doing that to use a memvar as a parent, code is restoring working area and index. It might be related with active index (ie: a filtered one).
>Cetin