>You are correct, running the query will use any tables it needs to that are not already in use and leave them in the used state when the query completes. However, he query will not upset the existing relationships. If you are concerned about movement of the record pointer why not just store the current record (recno()) for any table that concerns you, run the query then move the record pointer back to where it was before the query executed.
>
>>>>If I already have table A and B open where a relation is set the A is related to B (parent child) and I open a view, USE view_B_C. This view has B as the parent to C in a join. Will the view open another instance of B to do its work or will it use the B that is already and thus move B's record pointer. If this is the case is there a way to tell a view (created through the DBC) to not use existing tables?
>>>>
>>>>TIA
>>>
>>>I believe that the view does use an alternate work area for the "B" table to be opened for the view and will not cause problems with the A/B relationship set up previously.
>>
>>Thanks, I am hoping that this is the case, but I have a form doing strange things when I requery my view. I will perform more tests and see if I can find the problem. What I am concerned about is when I open the local view, the view cursor shows up, but so do all the tables needed for the view, except the ones already opened. That indicates to me that the view used my existing tables when it executed the requery. If this is the case then the pointers would have been moved on my B table. If this is the case then my relationship that was opened would not be correct.
>>
>>Well back to test and test....

I will test that out, but one problem is that if row buffering is on, and updates are pending, moving the record pointer will write the data to the table. So if the view moves the record pointer this will happen.