Hi Fabio,

>
>Appart from the fact I always try to avoid working with tables in this manner (e.g. Using views), I can only think of the following.
>

>a) If you have a big table, with large memo/blobs and the filter is 50% selective,
>the time for execute the query, re index it ,
>... can to be much worse than to open the table and to use set filter.

First of all. I'm not saying you cannot get arround it all the time, but trying to avoid this might be a good idea. There should not be too many cases where you would have to direct access to a large amount of records.

With regards to using views and large blobs and memo fields, you can choose to not include them into the navigational list, but rather load them when needed for display or processing.

Using views I think is a good practise, as this kind of developping is both applicable to using native VFP data as remote data. Though with remote data you'll have some more options of dynamically loading data when actually needed (In a simular way as using a table directly), this adds some more complication to it, so I wonder how many VFP developers do actually use this strategy.

>b) you must use always the NOFILTER clause into the SELECT
>in order to avoid that VFP uses a filtered alias.

Correct, or always avoid this by having SET DELETED = ON, and not having an index on deleted()

>c) my message has the scope to demonstrate that we must have the command:
>

>SET ORDER TO 0 DESCENDING
>

>that revert the natural recno() scanning.

I agree that might be usefull in some cases.

Walter,