I think Frank M. is probably correct. With row buffering even a SKIP 0 or any command which resets the record pointer (even if it doesn't move!) will commit the data making TABLEREVERT useless. Use Table buffering if you can.

>Hi fellows!
>
>A little catchy one for the lots of ya: I'm using a quitButton class (derived from a standard button) contained in a commandgroup on every forms that appear in my app. When clicked on, the button checks if the user was editing the data. If not, it closes the form, but if the form is in editing mode, it first asks for confirmation from the user, then reverts any changes made to the table, and then closes the form.
>
>

>&&the _linkedalias property of the commandGroup contains the name of the alias mentionned in the form's data environment.  i.e.: this._linkedalias="usagers"
>
>lcAlias = this.Parent._linkedalias && property of the commandGroup containing
>LOCAL liRep as Integer
>IF thisform.editing
>    liRep = MESSAGEBOX(this.Parent._message, 4+32+256+4096, "Confirmation")
>    IF liRep = 6 && user answered 'yes'; release the form...
>	TABLEREVERT(.F., &lcAlias)
>	thisform.Release
>    ELSE  &&  user answered 'no'; do nothing...
>    ENDIF
>ELSE
>    thisform.Release
>ENDIF
>

>
>The problem occurs on one of my form when the user create a new record. A blank record in appended in the table, which the user then populate. If the user decide to quit the form before he's finished and has saved the changes, the form go through routine described above except it doesn't remove the blank record, and throws a 1884 exception the next time you try to add a new record. I use the same procedure on 12 other forms with more than 12 other tables and it works just fine. The cursors in my form's data environments all have their BufferModeOverride property set to 3 (optimistic row buffering).
>
>Any clue as to what's happening?