Marcia
Thanks ever so much for your help. This will get me going again.

Gaylen






>Hello Gaylen.
>
>Thanks - How can I tell if they didn't move off the field with a tab or press the enter key to commit the changes?
>
>What most of us have done is to create a generic method on our data aware forms called "WriteBuffer" and call it from our Save method like so and then it is not an issue (You can also call it from your QueryUnload method):
>
>

>IF Thisform.WriteBuffer()
>  IF NOT TABLEUPDATE( 0, .F., 'Clients' )
>    MESSAGEBOX( 'Unable to save data right now...', 16, 'Major WAAAHHHH!' )
>  ENDIF
>ENDIF
>

>
>This code goes in the WriteBuffer method:
>
>

>LOCAL loColumn, loActiveControl, loControl, llRetVal
>
>llRetVal = .T.
>IF TYPE( 'Thisform.ActiveControl.Name' ) = 'C'
>  loActiveControl = Thisform.ActiveControl
>  IF UPPER( loActiveControl.BaseClass ) # 'GRID'
>    *** If there is code in the valid method of the active control
>    *** And the entry is invalid, the error message will display
>    *** But the rest of the code code will continue to run and save
>    *** the bad data anyway. So we cannot just issue a SetFocus()
>    IF NOT EMPTY( loActiveControl.Valid() )
>      *** We still have to cause the Valid to fire to update the data
>      *** from what is in the buffer because the previous line
>      *** does not cause the Valid to fire, it merely runs any code
>      *** in that method
>      loActiveControl.SetFocus()
>      llRetVal = .T.
>    ELSE
>      llretVal = .F.
>    ENDIF
>  ELSE
>    FOR EACH loColumn IN loActiveControl.Columns
>      IF loActiveControl.ActiveColumn = loColumn.ColumnOrder
>        loControl = EVAL( 'loColumn.'+ loColumn.CurrentControl )
>        IF NOT EMPTY( loControl.Valid() )
>          loControl.SetFocus()
>          llRetVal = .T.
>        ELSE
>          llRetVal = .F.
>        ENDIF
>        EXIT
>      ENDIF
>    ENDFOR
>  ENDIF
>ENDIF
>
>RETURN llRetVal
>

>
>Why does a view give an update confict error when it doesn't if you use a table as a recordsource.
>
>The usual reason that I have seen for an update conflict is when the underlying table has some fields that are populated using default values. If you add a new record to the view, commit the changes, and then try to edit the view and save the edits, you typically get an "Update Conflict error". The solution is to requery the view after saving the newly added record.
>
>Other than that, without seeing your code, it is difficult to hazard a guess about what is going on < s >.
>
>Since it is only one field they can update, I probably will just update the unlying table to that view from the valid event of the grid textbox using the SQl update command.
>
>You did not say that this was a data entry grid. That is a horse of a different color. Which version of VFP are you using? In versions of VFP prior to version 7, the Valid of the grid fired before the valid of the contained text box. This caused some very interesting problems < s >.