Thank you very much Mark for your response,

This is kind of what I was thinking....I hadn't started out that way...I had a few indexes with many fields because I am also used to using indexes for ordering purposes.

I appreciate your help,

Paul Acton

>Over 99% of my indexes are on 1 field. Keep in mind that if you have an index on single fields, the following where clause is Rushmore optimizable if all 3 fields are indexed:
>
>... where Field1 = value1 and Field2 = value2 and Field3 = value3 ...
>
>If you have an index on upper(lastname), the following is optimizable:
>
>... where upper(lastname) = "SMITH" ...
>
>As for a SEEK, you can Seek on the current single-field index, then use locate:
>
>LOCATE FOR FIELD2 = VALUE2 WHILE FIELD1 = The_Value_Seeked
>
>>The DBMS language I had used for DOS had a limitation on the number of indexes we could have so I am very accustomed to making compound indexes involving many fields.
>>
>>As I am becoming more familiar with the way VFP and Rushmore works I am beginning to wonder if it isn't better to create most of my indexes based on one field.
>>
>>The only down side I see to doing this is that I wouldn't be able to use seek statements if my search criteria involves more than one field. But then I guess I could use a locate for with multiple indexes.
>>
>>I know there would be exceptions to the rules where I would want more than one field in an index...But, I am just curious on how some of you set up your indexes.
>>
>>Thanks for your time,
>>Paul