Logo

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.

Positive number

Find the next changed record after record nStart.

cAlias

Character

Look for changed records in the table open as 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.

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).

.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

See Also

Buffering, CurVal(), GetFldState(), OldVal(), SetFldState(), TableRevert(), TableUpdate()