In the VFP help file on SQL Select in regards to buffering, it says:

"If the cursor uses row buffering, then current record is committed before the statement is executed. "

I find that rather strange. It's kind of like saying "you can select from a buffered record, but we'll do it by committing the buffer's content, thereby saving the record and making it nonbuffered." (Talk about cheating and unintended consequences.) Is that statement correct? In testing, I found that it didn't seem to be correct. For instance, I could have some buffered, uncommitted data using row buffering and I could select the data and print it (which is what I'm needing to do in this case) and then I canceled the changes (a new record that I added), exited the program and found that the new record had not been saved to the table. In other words, it behaved like I'd expect and I'd want it to behave.

But today I've run into a problem. If the user happens to try to print something that would cause a "uniqueness" error on the PK, then it reports this error at the time at the time the SQL statement runs. This only happens on a commit. You can populate a field with a duplicate value from another field that is a primary or candidate index as long as it's buffered. The error only occurs when you execute the TABLEUPDATE command. So . . . some behavior seems to indicate the data is not committed and some seems to indicate the data is committed. What's the real answer here?

Russell Campbell