>This is not as bug. It is how VFP optimizes a select command. If it can, VFP will simply use the table again in another work area and set a filter on it.


Yeah. VFP documentation does warn that it attempts to optimize SELECT queries and it provides a means for disabling the optimization, so...it's a feature. Still, the way the related error presents itself in this case is confusing. I'm really complaining about the error diagnostic that resulted in this situation. And, I guess I'm grousing a little bit too, because I cannot see any good reason for the one tag limitation you explain below.

>Now,why is there an error when VFP uses the filtered table. Because a cursor created with SELECT is read-only and creating an index causes a write operation to the dbf header for the view. When you use notfilter you have a temporary DBF that has no indexes on it and you can create one index tag. Attempting to create a second one will give you the read-only error. When VFP has used the table again and the table has an index, then your index command is trying to create the nth index tag and cursors for SELECT only allow one tag.

Fine. This is how VFP works. If it works this way because of some symmantical quality of SELECT-SQL which must be maintained for reasons of standardization, I can sympathize. But the behavior you describe above sounds more like a limitation resulting from some hidden (perhaps historical) implementation difficulties. It's not logical to be told you cannot write to a readonly file when (a) you know damn well it's normally writeable and (b) the INDEX command, as documented, is supposed to be creating a tag in either (a) a separate compound index file already associated with the table or (b) a new compound index file which is created implicitly. And what's really whacky is that if you happen to try the same thing with a bona-fide readonly cursor, it does let you create at least one tag.

And while we're on the subject; why only allow one tag? A .cdx file is supposedly being created? In the case where I've explicitly used the NOFILTER clause, what sense does it make to limit me to one tag?

Now that I understand SELECT-SQL better, I admit that there are better ways to use it and avoid the need for a temporary tag altogether. Still, I ought to expect reasonable results from a legal command feature of the language - a solution that might reasonably occur to any less experienced developer - and the one tag limitation ... when nominally creating a multi-tag .cdx file ... seems like strange behavior to me. That's my beef.