>What kind of error would you get if you use a filtered table result in another SQL?

'"Yourcursor" must be created with SELECT...INTO TABLE' is the error you'll see.

>SELECT * FROM mytable INTO CURSOR mycusor where eff_date = hold_date
>SELECT table2.thing mycursor.thing2 ;
>from table2, mycursor ;
>where table2.key1 = cursor.key1 ;
>into cursor mycursor2
>
>I have code similar to the two above SQL statements in multiple places. Sometimes even 3 or 4 SQL statments that all use the results of the previous SQL.
>Brenda


You've gotten lucky then. It doesn't happen in all cases, but it *can* happen. To see if your resultant cursor is a filtered view or not, use DBF(yourcursor) and see if it's the same as your table or some tempfile (.tmp). If you use the NOFILTER clause, it can't happen, you'll always get a .tmp file.



>
>>In this case, I don't think it matters. Where it does matter is that you >cannot use a filtered table result from a SQL SELECT in any additional SQL >SELECT statements. You also can't use the USE AGAIN trick below to make it >writable.
>
>
>>>Why and when does it matter that the cursor is really a filtered table?
>>>
>>>Brenda
>>>
>
>
>>>>
>>>NOFILTER makes sure that the new cursor is created as a result of SQL >statement.
>>>IF you do not include NOFILTER, VFP may just filter the table in question and >show the result under your cursor name, but if you check DBF() function for >both the source table and the cursor you will see that it is pointing to the >same table.
>>>
>>>If you want to update the resulting cursor you may SELECT... into table (as >you do) or SELECT... INTO CURSOR mycursor NOFILTER, then make it updatable by
>>>USE DBF("mycursor") IN 0 AGAIN ALIAS myupdatablecursor