Thanks for showing me this (and taking the time to do so)

.......Rich

>>>>>>That's wrong again. I think, when you use AGAIN you have to use different alias.
>>>>>>
>>>>>Not true, VFP create a name for you!
>>>>
>>>>Doesn't matter, it still would not be STUD < g >. You have to close that newly opened table, not the originally opened STUD.
>>>
>>>And the code do this!
>>>
>>>Update: except a copy/past error :)
>>>

>>>select 0
>>>USE Stud AGAIN
>>>APPEND FROM DBF("csrCourseStats")
>>>USE
>>>

>>
>>I was reading this thread and thinking how much simpler this is that checking to find if the table was open, etc.
>>
>>Then I had a different question about an area I don't thoroughly understand.....
>>
>>Let's say that Stud is currently open. You open it AGAIN, append the records, and close the second version.
>>
>
>The thing is more complex, because it depends if Stud is open only in this datasession or also in others.
>We suppose that is open only in this, otherwise I have to write an long script.
>
>>What problems might there be reflecting the appended records back to the original work area with each of the various buffering options? Or if you have a transaction running? If you close the first one, are there any chances that you could lose the appended records?
>>
>
>If you have a transaction,
>every datasession's transactable table it enters into the transaction.
>Every writing remains inside the transaction,
>even if the table is closed in all the workareas.
>
>You imagines the transaction as a datasession's buffer.
>
>This is a sufficient complex example with VFP9:
>

>CLEAR
>CREATE TABLE freeTable FREE (someField C)
>USE
>
>* DEFAULT NO BUFFERING
>CURSORSETPROP("Buffering",1,0)
>
>USE freeTable
>
>BEGIN TRANSACTION
>
>* THIS IS NOT TRANSACTABLE
>APPEND BLANK 		 && this is out of transaction buffer
>? RECCOUNT(),RECNO() && 1,1
>
>ROLLBACK
>BROWSE TITLE "RECORD IS INTO THE FILE"
>
>* PUT THE TABLE INTO THE TRANS SPACE
>MAKETRANSACTABLE()
>* ALLOW BUFFERING
>CURSORSETPROP("Buffering",5)
>* ADD A BUFFERING RECORD
>INSERT INTO freeTable VALUES ('A')
>? RECCOUNT(),RECNO() 				&& 2,-1
>
>* BUILD A DATASESSION BUFFER
>BEGIN TRANSACTION
>* THIS ADD A BUFFERING RECORD INTO THE DATASESSION BUFFER
>INSERT INTO freeTable VALUES ('B')
>? RECCOUNT(),RECNO() 				&& 3,-2
>* THIS ADD A BUFFERING RECORD INTO THE DATASESSION BUFFER
>INSERT INTO freeTable VALUES ('C')
>? RECCOUNT(),RECNO() 				&& 4,-3
>* THIS SEND THE TABLE BUFFER INTO THE DATASESSION BUFFER !!! ATTENTION !!!
>TABLEUPDATE()
>? RECCOUNT(),RECNO()				&& 4, 2
>
>SELECT 0
>* OPEN THE SAME TABLE ( THIS DON'T OPEN THE FILE )
>* NOW IT IS TRANSACTABLE
>USE freeTable AGAIN
>* NO BUFFERING
>? "NO BUFFERING",CURSORGETPROP("Buffering")=1
>* THIS RECOD GO INTO THE DATASESSION BUFFER
>INSERT INTO (ALIAS()) VALUES ('D')
>? RECCOUNT(),RECNO()				&& 3,3
>BROWSE TITLE "Observe the C record, but the B is not visible !!!!"
>* this don't change datasession buffer
>USE
>
>SELECT freeTable
>* YOU SEE THE UPDATED RECORD "C"
>? RECCOUNT(),someField,RECNO() 	&& 5,'C',2
>
>* NEXT :
>* SEND THE "C" AND "D" INTO THE FILE,
>* AND "B" INTO THE TABLEBUFFER
>END TRANSACTION
>? RECCOUNT(),someField,RECNO() 	&& 5,'C',2
>GO BOTTOM
>? RECCOUNT(),someField,RECNO()	&& 5,'B',-2
>* this revert THE TABLEBUFFERS 'A','B'
>TABLEREVERT(.t.)
>* RESULT 3 RECORDS
>BROWSE
>USE
>

>Interesting it is also the analysis of RowCache/OLDVAl/CURVAL/FileCache,
>but it will be for another time.
>
>
>>My applications have never approached this level of complexity, but I'd like to be ready if they do.
>>
>>Thanks........Rich