>>>>>>>Interesting approach. I still don't see how to guarantee that the TMP file returned by DBF() exists. Isn't it possible to get back a file name for the TMP file that VFP will create when the cursor becomes too large to fit in memory? If I could guarantee that the cursor would have a disk presence, then your approach would solve my problem.
>>>>>>
>>>>>>Edwin,
>>>>>>
>>>>>>A cursor created with CREATE CURSOR always has a disk presense. Cursors created by sql select may be filtered versions of the original table, but create cursor always creates a dbf on in the temp directory.
>>>>>>
>>>>>>The question that I have is, if you are creating the cursor why do you need to change its structure, why create it with the right structure in the first place?
>>>>>
>>>>>Jim:
>>>>>
>>>>>True, any cursor created with CREATE CURSOR will (under LIST STATUS) show up as a .tmp file in the TEMP directory. But if you open Explorer and look at the TEMP directory, you will not always see that cursor's filename. In that case, VFP (I think) just keeps the cursor in memory.
>>>>
>>>>I think the best way to prove (or disprove) it, is trying to run Select * From tmpalias. That's the command which should catch the difference. Actually, I didn't check the thread from the beginning and don't understand practical reason for all this stuff :) In regard to 'modifying cursor structure', I think it's consistent enough to close cursor (USE) and start new one with CREATE CURSOR.
>>>
>>>Hi Ed:
>>>It would help to look at the thread. This part is really a side issue. The idea is to use cursors as a view into data. The cursors will be bound to controls. It would be useful to be able to modify the cursor structure with as little disturbance to the bound controls as possible.
>>>
>>>One problem with your approach is that if the cursor is the record source of a grid, special care has to be taken that it doesn't notice that its record source is gone. If the structure is altered in place, adding a field to the cursor should not cause any problems. Other types of bound contorls could also be a problem. Of course, if a field is removed even the new approach would get more complicated.
>>>
>>>Thanks
>>
>>I understand that there is natural reflection to avoid hidden problems as much as possible. However, this case is transparent enough. I use cursors as Record(Row)Source alot, and the only thing you should do here is to 'wake up' vfp each time you rebuilt a cursor, e.g.
>>IF USED("tmp")
>> Select tmp
>> USE
>>ENDIF
>>CREATE CURSOR tmp ....
>>INSERT INTO tmp ... && or use another way to populate data
>>Thisform.Grid1.Recordsource=""
>>Thisform.Grid1.Recordsource="tmp"
>>Thisform.Grid1.Refresh
>>Last three lines are not always necessary, but it's a good habit to add them.
>
>In the above code fragment the code that is rebuilding the cursor is located in the form that uses it. I intend to have the cursor maintained from outside of the form. If fields are removed I'll notify the affected forms, but if a field is added I'd rather save the overhead.

I wasn't really going to convince you. If you like your approach and it works, then it's best for you. Usually, the reason to keep temp tables inside a form is derived from default/private datasession concept.