>>
>>Here is my test code.
>>
>>USE cmi!lv_vendors
>>INDEX ON cid TAG primary
>>? DBF() && = F5PW000M.TMP
>>? CDX(1) && = F5PW000M.CDX
>>
>>= REQUERY()
>>
>>? DBF() && = F5PW000Q.CDX
>>? cdx(1) && = F5PW000M.CDX
>>
>>Note the last character of the temp name in the DBF() after the Requery().
>
>
>There is a workaround which is acceptable.
>EverY time you index on a view, do so with the following code:
>IF EMPTY(CDX(1))
> INDEX ON fexpr TAG tagname
>ELSE
> INDEX ON fexpr TAG tagname OF (CDX(1))
>ENDIF
>
>BUILD YOURSELF A LITTLE FUNCTION TO do this which takes the tagname and index expression as a parameter.
>
>
>You will still have a non-structural index after the first requery -- but only one cdx file no matter how many times you requrey and build indexs. You won't have to reindex or use idx files...
>
>You will have no signficant disadvantages from the fact that they are non-structural cdx's.
>
>BTW -- the reason this has not been encountered more is that in most applications you can build all your view indexes when you first open the view, and do not need to build additional tags.


Gar,

Yes, that will work, and as long as the views are relatively small, not a problem. But when the view is a large lookup table, say all the customers with incremental search needs, reindexing on every Requery can result in a significant performance penality.

And performance is the reason for indexing on the fly. I use a commercial framework (Visual ProMatrix) which indexes views as needed to eliminate the upfront indexing time if an index may not be needed in a given session. The developer can choose which indexes to create at load time.

But if the view file name changes with every Requery, the CDX created is no longer structual, so VFP will not longer maintain it as it would a structural CDX. As long as it is the active index file, I suppose all will be well, but when a new structural CDX is created, the original CDX is in jeopardy, and as it will be the index taking care of the primary key...well I think you can see the problem.