>>Sorry Tore, I misstated the problem - there are no errors on the other hand it has no visible effect
>>I assumed the query table would open up to allow edit after the readwrite command.
>
>It becomes visible only when you try to change a value in your cursor and don't get an error. Mind you, it doesn't change anything in the source table(s) - your changes live only as long as the cursor lives. It may change the source tables if you went through certain steps (there's a way to make cursor updatable back to the source table, even if it's on a SQL or other server, and it includes setting many properties, like table to update, source field names, primary key name).
>
>And, ahem, there's no query table. The cursor is a cursor, a table-like entity which behaves generally like a table (has alias, buffers, recno() and other alias-related functions work on it) but does not necessarily exist on disk, and if it does, it's a randomly named .tmp file, which vanishes (along with any indexes) as soon as you close the cursor.
>
>The other significant difference: you can have one structural index on a readonly cursor; on readwrite, you can have as many as you want.


vfp9sp2 allows more than one index on a readonly cursor

Think vfp9sp1 only allows one