That works, also. But when it comes to FRX, DBC, etc., I prefer to select the data into a non-updatable, read-only cursor unless I am doing development work on files that have been backed up and absolutely verified. Many a time I have started typing when I was sure I was at the command window only to discover I was still browsing the table. I also issue a _screen.closable = .f. in my VFPSTART.prg so I do not accidentaly close the wrong window when developing. I do not mind typing QUIT from the command window. Distractions Happen

>Mark,
>
>You could open the container as a table like this:
>
>OPEN DATA MYDBC
>USE MYDBC.DBC IN 0 AGAIN
>
>Couldn't you?
>
>Jonathan
>
>
>>>Couldn't you just open the report as a table and do a COPY TO to get your temporary table for modifying? I saw a suggestion similar to this on a different thread recently. Of course, you would have to do file cleanup yourself, unlike the cursor solution.
>>>
>>>>Josh,
>>>>
>>>>I used FILE(DBF('cCursor')) and it returns FALSE. Very interesting! So I could use a CREATE TABLE and then kill that off afterwards I guess.
>>
>>The reason you do not want to open the FRX as a table is that by using a SELECT, you will not create an error if some other user happens to be running the same report at the same time. Doing a SELECT * FROM THE_FRX INTO WHATEVER, prevents this from happening. The same holds true for SELECTing against the DBC -- you can do this even if the DBC is already open as a DBC. The following works:
>>
>>OPEN DATA MYDBC
>>select * from mydbc.dbc into cursor crsDBC