>>>>I believe, that's it's fully optimizable, but assuming that
>>>>1. return of significant amount of records,
>>>>2. significant number of joined table,
>>>>3. order clause on result,
>>>>4. main one- functions in result field set (they will fire for each record),
>>>>12 min might be trustworthy.
>>>>I believe you should reconsider your interface approach. As i guess, you use 'membergrid' cursor as Grid.Recordsource. Probably, 115K is not very representative for users, and it would be more appropriate to coleect smaller recordset, e.g. for particular 'ikeyproduct'. Also, it's not necessarily to join all related tables. Instead of this, you could combine two tables, and add some grid.column.buttons to open dialogs (e.g. 'memberdata' dialog).
>>>
>>>You have interestings suggestions. Thanks for your help
>>
>>One other suggestion. I don't know if this is feasible but you might try the sql statement without the PADR. Do your formatting of text after. I don't know if this will make a difference but it's worth a try.
>>
>>HTH
>
>I haven't been following this whole thread, but did pick up this particular message. Most functions included in SQL statements will slow down the query considerably. As Dan stated, it is better to manipulate data after the Select, unless the manipulations are required to create a match condition.

Also, I have found that the ORDER BY clause can slow performance down. If I am SELECTing into a cursor, I will make the cursor R/W and index it. If it is a table, I just index it.