CursorAdapter.CursorRefresh doesn't seem to work when starting a VFP transaction 1

[xinjie]

Hi,everyone

I am a newbie in terms of using CursorAdapter. My development environment is VFP9 SP2 7423 . I am having a very confusing problem.

I have a document entry UI with a parent-child table structure. The child table needs to display the record corresponding to the parent table when the parent table's record pointer moves.

In the BeforeCursorFill of the child table, I added the following code:

LPARAMETERS luseCursorSchema, lNoDataOnLoad, cSelectCmd
 
TEXT TO m.cSelectCmd ADDITIVE NOSHOW TEXTMERGE PreText 2
	Where ParentID = ?Parent.ID 
	Order by NO 
EndText

With this, I can get the results I want in browse mode.

The problem is in edit mode. When starting to enter a new record, I first execute the Begin Transaction command. After the records are added to the Parent table, I need to refresh the child to get an empty result set. Like this:

*!* Parent
Append Blank
Child.CursorRefresh

But my Child are not empty result sets, and it seems that CursorRefresh doesn't do anything. It still has the records that were there before the edit.

I tried to change cSelectCmd in (Child's) BefroeCursorRefresh , like this:

LPARAMETERS cSelectCmd

TEXT TO m.cSelectCmd NOSHOW TEXTMERGE PreText 1 + 2 + 4 + 8
    Select * From Child Where ParentID = ?Parent.ID Order by NO 
ENDTEXT

But the results were also disappointing and not what I was looking for.

I'm confused as to whether CursorRefresh in a VFP transaction is the result I'm seeing, whatever it is. Or is there something wrong with my approach that is causing the result to not be what I expect?

Any comments or suggestions are welcome!

Thanks in advance!

 

[Chris Miller]

The question that arises from all of this is, why is REQUERY() actually disallowed within a transaction? It must counteract the transaction mechanism used by VFP.
As SQL Select is not disallowed you can produce the same result - a cursor - from SQL, so what really is the point of disallowing REQUERY which does nothing else but n SQL Select query. The only difference is that REQUERY (and CursorRefresh) update the contents of the already existing cursor (grid friendly) and a straight forward SQL-Select (similarly a CursorFill) does destruct a cursor of the same name (grid unfriendly) and reinstates it in the end.

The real solution is to not start a transaction when you start a session about a set of records, but instead rely on buffering keeping other users away from your new private data and using transactions only when actually saving the changes in one transaction that can be rolled back when something along the way of saving that set fails.

Chriss