BUG: UNLOCK Command Commits Changes to Row-Buffered Records

MORE INFORMATION

Steps to Reproduce Problem

   SET DEFAULT TO C:\VFP
   CLEAR
   CLOSE DATA ALL
   IF FILE('test.dbc')
     DELETE DATA test
     ERASE "XXX.DBF"
   ENDIF

   CREATE DATA test
   CREATE TABLE xxx (dbkey i, field1 c(10))
   USE IN xxx
   USE xxx SHARED

   INSERT INTO xxx VALUES (1, 'string1')
   INSERT INTO xxx VALUES (2, 'string2')
   INSERT INTO xxx VALUES (3, 'string3')

   && Turn on optimistic row buffering
   SET MULTILOCKS ON
   =CURSORSETPROP('buffering', 3)

   GO 2
   ?' Before RLOCK() GETFLDSTATE():' + CHR(9) + GETFLDSTATE(-1)

   && Lock the record for update, show that nothing has changed
   && as far as the record is concerned.
   =RLOCK()
   ?' After RLOCK() GETFLDSTATE():' + CHR(9) + GETFLDSTATE(-1)

   && Update the second record.
   REPLACE field1 WITH 'changed'
   ?' After REPLACE GETFLDSTATE():' + CHR(9) + GETFLDSTATE(-1)

   && Release the lock - note that the changes are now
   && committed even though there was no explicit update done,
   && either through an =TABLEUPDATE(.T.) command or SKIP 1/SKIP -1
   && command.
   UNLOCK RECORD (RECNO())
   ?' AFTER UNLOCK GETFLDSTATE():' + CHR(9) + GETFLDSTATE(-1)

   && Go back to old data.
   =TABLEREVERT(.T.)
   BROWSE NOWAIT

   && The data is not rolled back to its original state because the
   && UNLOCK command has committed the revisions to the record. Rather
   && than using an UNLOCK() command, use a SKIP command to move the
   && record pointer or issue the TABLEREVERT/TABLEUPDATE commands.