>Got a really weird one here. I have a table from a client app where Rushmore is not kicking in for most of the tags. The table has over 100 fields. (I didn't design this; I inherited it.) There are 19 tags; 10 of them are filtered. Obviously, I'm not expecting those to help with optimization.
>
>When I test queries with SYS(3054), only one of the other 9 tags contributes to optimization. That tag corresponds to the table's effective primary key (it's a regular tag, but it's the PK field). When I run a query that filters on any of the others, I get optimization of "None".
>
>I've rebuilt all the tags from scratch. I also tried adding a tag on a previously unindexed field and using that in a WHERE clause. No optimization.
>
>I've tried this with two different copies of the table in different folders with the same results.
>
>I made a copy of the table and started indexing one tag at a time and optimization worked as I expected. I thought maybe the problem was the presence of the filtered tags, so I added one of those, and optimization still worked as I expected for the other tags.
>
>Anybody seen anything like this before?

A SWAG, is SET COLLATE set to anything other than MACHINE? Is it possible the tags were created while SET COLLATE was not MACHINE, even if it's MACHINE now (check with IDXCOLLATE())?

Is the table part of a DBC database?