Recently I took the advice of the Hacker's Guide and added an index tag on DELETED() to my primary data tables (to help speed up data access). This caused some of my code to break. The snippet that worked, prior to adding the new index tag was:

SELECT * FROM mytable INTO CURSOR mycursor
SELECT mycursor
INDEX ON some_expression TAG mytemptag

The intent of the above snippet is to create a temporary cursor and a temporary compound index file that are automatically deleted on exit from the application. And prior to my adding the permanent tag (on DELETED()), the snippet worked just fine.

After adding the new permanent tag on DELETED() to mytable, the INDEX ON command (in the snippet) causes an error (attempt to write to readonly file mytable.dbf????)

Huh? why is an index command trying to write to mytable.dbf when i'm trying to create an index into a cursor I've created which is just an image of mytable.dbf???

As I'm sure all of you wizards out there have realized by now, it's because (for some reason) VFP had chosen not to actually create a cursor when it encountered the SELECT-SQL for mytable ... it decided to simply filter mytable.dbf. And (I'm guessing here), since mytable.dbf already had it's own associated .cdx file, instead of creating a new index file, VFP attempted to add the temporary index to the already existing .cdx file which is a no-no for cursors that are supposedly readonly when created by SELECT-SQL.

Using NOFILTER in the INTO CURSOR clause of the SELECT-SQL cures the problem, but the whole mess is still a VFP bug, IMHO.

Here's some stuff I think is pretty strange:

1. Adding a DELETED() tag to mytable.dbf caused VFP to implement the cursor with a filter. Without the DELETED() tag (there were already two other tags in the related .cdx file), VFP chose to create a real cursor. I'm not sure if it's the DELETED() tag that caused VFP to 'optimize' differently or if its based on the number of tags in the related .cdx or what.

2. This is the really weird thing: VFP complains about writing to a readonly table when you try to add an index tag to a cursor that's actually implemented by filtering a writeable table (with a writeable .cdx file), but if VFP has actually created a truly readonly cursor it doesn't fret a bit when you try to write a new tag to its (newly created temporary) .cdx file. In other words, it gives a readonly error when you attempt to write to a file that's actually writeable and its happy as a clam if you try to write to (the index file of) a truly readonly file. Go figure.

I understand that there may be valid reasons for VFP to work this way. But at the very least, the error diagnostic should give a clearer indication of what VFP is really complaining about - namely, trying to write to the related .cdx file (which happens to be temporarily read only because it is being used as an adjunct to a simulated, read-only cursor).