>>>Donnot forget, that reindex will use the actual collate sequnce!
>So the right order of commands:
>1. remove indexes
>2. change to collate sequence you want (general, french, hungarian, anything)
>3. rebuild only the affected indexes
>4. change to other collate sequence you want (machine)
>5. rebuild the affected indexes<<
>
>Thanks for your answer and I agree with the above, but I'm using Stonefield's Toolbox to make these changes which rebuilds the entire index when you make a change to one of it's tag.
>
>Also, in the application, when you do a version update with changes to the database it will do the database update and remove the indexes (.CDX) and rebuild them. Even when the user want's to reindex the tables, Stonefield will first remove the .CDX then rebuild it according to the data dictionary .DBC .
>
>But with all this in place I still have the problem since I changed from general to machine and I cannot see where to look anymore.

I agree with Bela, I've had the same experience with the Hungarian and (since there is no Serbian) Slovak collating sequences.
One thing you can do to see how things are is to simply open the table(s) and DISPLAY STRUCTURE - it would give you the collating sequences for the simple indexes (where the key is a single field). Or, alternatively, you could use the IdxCollate() function to determine each tag's collating sequence.

Any index maintenance tool must do as SDT does, because there's lot of info in your .dbc which relies on the existence of your indexes (like permanent relationships, RI, which key is primary), so it has to save that info from the .dbc, destroy the indexes, and rebuild this info once its done with creating the indexes.

A word of warning: what Bela has said about "other collating sequences are for names only" is crucially important. Other collating sequences use double-byte keys to maintain weights of certain character pairs (which makes German 'u-with-umlaut' equal to 'ue', or makes the c-with-caron a separate character collating after c and before d regardles of its ascii value, which is above 128). Applying these rules to anything but strings may yield unpredictable results. Don't even try them with integer, date, currency or other type of keys.

BTW, I think Rushmore doesn't work in SQL statements with other collating sequences - or at least gives you suboptimal results if you have a mix of them in the same statement (i.e. if it's trying to use tags created in different sequences). I may be a little rusty in this area, since it's been almost two years since I last had anything to do with this, and then it was FPD2.6 - check "SET COLLATE, specifying sort order with" in help.