>>>I always though I was able to create a SQL cursor (read-only) based on previously created SQL cursor (read-only) but I guess not. I get an error something like "Must SELECT...INTO TABLE" on the second attempt. Thus, I have to do USE DBF("cursor") AGAIN... before the second SQL-SELECT statement. Any reason why?
>>
>>Hi John,
>>
>>It may be that the problem has to do with the way VFP creates the cursor. I've never had this problem with a cursor that had to have a physical presence on the disk. I do this all the time with queries that SUM() values and group them together, with this problem. However, it does occur when the query produces a filtered result without having the information forced to the disk.
>>
>>You might try adding the NOFILTER clause to see if this overcomes the problem.
>>
>>hth,
>
>Thanks George. Actually, I just tried directly accessing the original cursor w/o going through DBF() and it now works. Nothing has changed but it now wants to work. Anyway, I'll add the NOFILTER claus just to be sure.

John,
The error message "Must SELECT...INTO TABLE" implies that the cursor is actually the original table that has been filtered, not a new temporary table (which is what most cursors are). An example would be SELECT * FROM ADDRTABL WHERE VAL(ZIP) < 72000. The resultant cursor with the alias QUERY is really ADDRTABL with a filter set to VAL(ZIP) < 72000. This cursor can't be used as the SELECT FROM in a subsequent query. Two easy solutions are 1. use the NOFILTER keyword which forces the creation of a new temporary table (as before the default alias would be QUERY) or 2. Do something adds a new field to the cursor thus preventing mere filtering on the prior table as in : SELECT *,.T. AS NEWFIELD FROM ADDRTABL WHERE VAL(ZIP) < 72000. Either way the resultant cursor can be used in the SELECT FROM of a subsequent query.
Good Luck,
Dore