>> BTW, what I meant in the previous post was
>> that I'd use an updatable view, rather than
>> a filter or a filtered index. Geez, I'm getting sloppy.:-)
>
>That won't solve the problem of not being able to use
>myfunc() in SET FILTER TO. You still cannot set filter
>to myfunc() when creating the view.

Since FPW doesn't support the updatable view (the view file not being the same thing) this is a moot point. However, in FPW, since a query is supported, and since a query can contain a UDF, you could use the function there.

>Without breaking up myfunc(), filtered index is probably
>the best (and fastest) solution to my problem. YOu probably
>need to include a filtered index in your updatable view.
>And frankly, I seldom use view files.

In FPW the view simply restores relations, indexes, field lists, open files, and, yes, filters, etc. In VFP, your updatable view would be based on an SQL statement.

>I haven't tried it, but I suppose I could use myfunc()
>as in index on ... for . But will the
>FOR-condition be remembered in the index?

Only those records which meet the for condition are included in the index.

George

Ubi caritas et amor, deus ibi est