GetNextModified()

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

`GetNextModified()`

Boy, do we wish this function had been around forever! It provides an easy way to find all the records that have changed in an editing session. It works only with table-buffered data. Pass it a record number and it finds the next record after that that has changed.

Usage

<a name=Usage>nNextChanged = GetNextModified( nStart [, cAlias | nWorkArea ] </a>
                                [, lNoFire ] )

Parameter	Value	Meaning
nStart	0	Find the first changed record in the table.
nStart	Positive number	Find the next changed record after record nStart.
cAlias	Character	Look for changed records in the table open as cAlias.
cAlias	Omitted	If nWorkArea is also omitted, look for changed records in the current work area.
nWorkArea	Numeric	Look for changed records in work area nWorkArea.
nWorkArea	Omitted	If cAlias is also omitted, look for changed records in the current work area.
lNoFire	.T.	Do not fire field, table, and index uniqueness rules (new in VFP 7).
lNoFire	.F. or omitted	Rules are fired.
nNextChanged	0	There are no changed records after record nStart.
	Positive number	The record number of the next changed record.
	Negative number	The temporary record number of a newly added record.

GetNextModified() uses the natural order of the table, not any index you might have in effect. So, GetNextModified(0) returns the lowest positive record number for a changed record. You proceed through all the previously existing records in record order, and then get the negative record numbers for newly added records.

GetNextModified() is another piece of the strategy for avoiding and resolving conflicts. As with the other related functions, you can use it either proactively or reactively. That is, you can try the TableUpdate() and, if it fails, use GetNextModified() together with CURVAL(), OLDVAL() and GETFLDSTATE() to figure out what happened. Or do all that first, resolve all the conflicts, then TableUpdate().

You can only use GetNextModified() when you’re table buffering. Try it on a row-buffered table and you get an error.

Remember that “modified” means you touched it. FoxPro isn’t smart enough yet to know if you changed it, then changed it back. Look at SetFldState() if you find yourself in that situation.

GetNextModified() has two weaknesses that make it more useful for figuring out why TableUpdate() doesn’t work than for using it to see if TableUpdate() will work. First, if the user changes a field in a form but doesn’t move off that field, GetNextModified() and GETFLDSTATE() don’t see that field as changed. Also, because GetNextModified() moves the record pointer, it fires row rules whether you want it to or not (you can suppress this behavior in VFP 7 by passing .T. for the lNoFire parameter). We think we’ll be sticking to the optimistic approach to saving records.

Example

<a name=Example>* Loop through an open table, finding all the changed records</a>
* and preventing rules from firing.
nNextRec = GetNextModified(0, ALIAS(), .T.)
DO WHILE nNextRec <> 0
   IF nNextRec > 0
      * This is an existing record. Check for conflicts.
      * Then save it.
   ELSE
      * This is a new record. Save it.
   ENDIF
   nNextRec = GetNextModified(nNextRec)
ENDDO