This can be even faster if it meets your needs. For example, if you have a lot of line items for a customer. SEEK the Customer ID and DO WHILE the table's Customer ID is what you need.
>Hi glenn, > >I know i'm stepping on ice, but when seeking records on more than one criteria, a SET FILTER in combination with SEEK can be far faster than a optmizable LOCATE. However, performance depends on the selectivity of the FILTER. > >Walter, > >>Seek cannot be beat for data retrieval based upon a single index expression. If you need to retrieve data based upon multiple optimized expressions the use either locate or SQL-Select. >> >>ie. Locate for state='MI' and city='TRAVERSE' or >>Selecte * from MyTable where state='MI' and city='TRAVERSE' >> >>Glenn >> >> >>>Moises, >>> >>>As Alex has said Locate can be as effective as Seek, however, you need to be very careful and ensure that your statement is Rushmore optimised or you will have a performance hit. >>> >>>Locate is powerful in that it will sequentially read through a table if it can't use Rushmore, however the downside is that it can be very slow. >>> >>>Regards, >>> >>>Aaron
Best,
DD
A man is no fool who gives up that which he cannot keep for that which he cannot lose. Everything I don't understand must be easy! The difficulty of any task is measured by the capacity of the agent performing the work.
