>>>>>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