FoxPro always worked this way. The filtered cursor will be created under following conditions:
- Only one table is referenced by query
- WHERE condition is fully optimisable and can be represented by SET FILTER TO
- Either all fileds from the table are selected or subset of fields can be limited by SET FIELDS command
Add Nofilter or ReadWrite clause to create a real cursor instead of filtered cursor.
>The following query produces not a cursor as expected but what appears to be the basetable use(d) again and filtered:
>
>
> SELECT Historicalreservations.* FROM Historicalreservations ;
> WHERE Historicalreservations.darrive > DATE() ;
> AND Historicalreservations.iguestid > 0 ;
> AND INLIST(Historicalreservations.rms_status,"C","A","U") ;
> AND Historicalreservations.iruid = xi_RUID ;
> ORDER BY Historicalreservations.darrive ;
> INTO CURSOR x_NextResv
>
>
>issuing MESSAGEBOX(SET("Filter")) in the command window produces the following:
>
>---------------------------
>Microsoft Visual FoxPro
>---------------------------
>DARRIVE>DATE().AND.IGUESTID>0.AND.INLIST(RMS_STATUS,"C","A","U").AND.IRUID=XI_RUID
>---------------------------
>OK
>---------------------------
>
>
>this was not happening until I added an index for deleted() to this table. Is vfp arbitrarily deciding that it is faster to open the table again and filter it than it is to issue select sql statement and create the expected cursor ?
>
>BTW issuing readwrite forces the cursor to be created correctly
--sb--