>I'm using a simple "INDEX ON UPPER(Title) TAG Title" type of statement. Since I'm indexing a view, I'm not even sure what you'd do to create a "non-structural" index: "INDEX ON UPPER(Title) TAG Title OF [viewname]"?

A non-structural index is created as an IDX. A structural tag is a CDX. That's all.

> Since views get created dynamically, the whole notion of structural seems obscure.

Well, you are creating a structural tag by using the TAG clause. If Rushmore needs to create an ad-hoc index, it will create an IDX (non-structural) index. It will create it _for_the_table_used_in_the_select. Not related, necessarily to the _view_ or it's indices.

>You might be on to something with Rushmore and the value of "criteria" but for the fact that the problem ONLY occurs when the user has opted to view the grid in some particular sort order (which they do by double-clicking on the column header, the CLICK event of which issues the INDEX command as described above).

Ah ha. Exactly the point, I think. You can reliably reproduce this for one index. I'd put SYS(3054,1) and see what optimization you're getting. If you can reliably duplicate it for one particular set order, try adding an index to the underlying table that matches what's needed in the view (just for an experiment).

>We have another application where users are updating and adding records to sorted views all the time without any errors. The only difference there is that the nature and number of the indexes is always the same; it won't vary from user to user. In the application that produces the errors, each user can sort on one or more fields, completely at their choosing and independent of what another user might be doing. We were wondering if, somehow, some of this was getting stored in the DBC and a conflict was arising because the indexes that one user was using on the view were different from those being used by another user.

Exactly, I think. This supports the glimmer I think we have. :)