INFO: Alternative to SCATTER and GATHER in the New VFP Model (129641)

MORE INFORMATION

Step-by-Step Example for Implementing Buffering in a Form

You can easily implement buffering in a form as an alternative to scatter and gather. The following example walks you through the process of creating a table with validation on a specific field and designing a form that uses buffering to enforce this validation on a form.

1. In the Command window, issue this command:

      SET DEFAULT TO \VFP\SAMPLES\MAINSAMP\DATA
   							

2. Create a new form.
3. From the View menu, choose Data Environment. From the Data Environment menu, choose Add Table. Add an existing .DBF to the data environment. To take advantage of field or record level validation, you must make the .DBF part of a database container and must have validation rules defined in the .DBC file.
4. Drag one or more fields from the data environment window to the form.
5. Set the Form.BufferMode property to 2 for Optimistic Buffering. This will set optimistic table buffering for any grids bound to data and optimistic row buffering for all other controls bound to a data source.
6. Add a command group to the form. Set the ButtonCount property to 2. Set the caption of the first button to "Save" and the caption of the second button to "Cancel."
7. To allow users to save changes to the table, add the following code to the command1.click method:

      lUpdated = TABLEUPDATE()
      IF !lUpdated
         =MESSAGEBOX("Update failed", 64)
      ENDIF
      THISFORM.REFRESH
   							

8. To allow users to cancel changes to the table, add the following code to the command2.click button:

      iRecords = TABLEREVERT()
      =MESSAGEBOX("Changes to " + STR(iRecords, 2) + " were discarded", 64)
      THISFORM.REFRESH
   							

9. Save and run the form.

Additional Considerations

You probably will want to add the following additional features to your form:

• Navigation buttons to allow movement between records.
• An on error handling routine to handle error 109, "Record in use by another."
• An expansion of step 7 to allow for common scenarios that would cause the tableupdate() function to fail. Possible reasons for failure include an inability to lock the record and the possibility that another user modified the record while the current user was editing it.

You do not need to write individual field-level validation routines for any table that is part of a database container (DBC). The form automatically accesses any validation rules or triggers contained in the DBC. The user won't be able to move the pointer (cursor) off of an offending field until a valid value is placed in the field.

You do not need to write code to save the initial values of each field. The CURVAL(), OLDVAL(), and GETFLDSTATE() functions can be useful in handling situations where a different user has modified the current record.