>Hi Ed,
>
>Sorry to disagree, but i have the same code at another application and it works OK! I have many indexs for a IDX file, on a temporary cursor, which is not updatable.

The issue is not if it is updatable, but if it is writable. The results of a SQL Select to a cursor are not writable, unless you force it to write a temporary file, and reopen the temporary file with the USE statement. Views are generally writable - even if you can't write the changes back to the base tables, you can append and modify data in the view.

The index rules:

Any cursor can have a single tag in a structural CDX
Any writable cursor can have as many tags in a structural CDX as you want
You can have an unlimited number of IDXs on a cursor
Structural CDXs on cursors are deleted automatically when the cursor is closed
IDX files on cursors are not deleted when the cursor closes

The result of a SQL SELECT (not a View) is not writable as created. It can be made writable if it is a real temporary file rather than a filtered view, and opened via USE...AGAIN

>The only difference is: for this case, this cursor can be removed and created with new information at the same form. "Why don't you delete the records, instead of removing the cursor?" you may asking yourself. The reason is that cursor can have new fields, depending of some choices of the user (choosen at the form).
>

I think you're being presumptuous and pompous here; I have some clue about how file access works, and even about how to offer my users a flexible user interface, but you needn't believe that if you'd rather not. I'm certain thatsomeone here might benefit from your approach. Visual AccountMate has had a similar feature in their data browser for a while.