>>select ... into cursor anyothername
>>use (dbf()) again in 0 alias dbfname
>>select dbfname
>>
>>That's all you have to change. Not too much work in both cases; I'd prefer cursors, because they're, by default, created on your temp drive, i.e. not on the server machine (check the config.f* settings on both machines for tmpfiles, sortwork, editwork, progwork), and they're automatically deleted when you close them, keeping the system free of unnecessary files. In cases where the selected data are to be used later, then it'll be tables, of course, but then you must take care that either their names (or location) be different for each user, or use the error routine as described in the rest of this thread.
>
>>Dragan,
>>
>>Thank you very much for your advice, I like it and will do it that way because it lends itself to the way my program is done. Also thanks for the info on 2.5 to VFP conversion. I will get back to you on that one.
>>
>>Thanks as well to all ohters who gave ideas, both here and at DevCon.
>>
>>Alex
>
>Dragan,
>
>I finally tried your suggestions. For your information, the first scenario seems to work, but the 2nd one doesn't.
>
>I also made a small modification in order to for housekeeping to be easier: I set tempfile = SYS(3)+'.tmp'. I am now trying to open it in the tmpfiles directory.
>
>Thank you again,
>
>Alex

For tmpfiles directory, there's an easy shortcut: Somewhere at startup of the app, I issue a thing like this:

public _work
create curs dummy (c l)
_work=addbs(justpath(dbf()))
use

Then, later in the app, anywhere I need a temp filename, I use tempfilename=_work+sys(3). I don't give it an extension, because it may want to be an index, .dbf or whatever, so it'll get one when it needs one. Most of the time I actually hardcode it as
Public _work
_work="C:\Scratch\"
though I know I should be using the full approach - but then, I take care every machine has the C:\Scratch\ directory.

The reason why the other scenario might not work always is that it may not really create a .tmp file for the cursor, but use a filtered view instead. Worked for me practically always, probably because my SQL's were not straightforward and almost always had some added fields, so I don't remember ever getting a filtered view in FPD instead of a real-file-on-the-disk cursor. You may try adding a dummy field to your SQL selects where the other scenario doesn't work.