1. Ensure that all fields used in relations and filters have indexes.

2. Review relations and filters in queries to ensure optimal usage of indexes. For example, using left(a.field1,10)=alltrim(b.field2) is normally a poor choice even if both field1 and field2 are indexed. You can use the SYS(3054) function to determine efficiency.

3. SET DELE OFF and add AND NOT DELETED('alias1') AND NOT DELETED('alias2') ... etc. to the end of filter clauses, or create an index on DELETED() to tables if SET DELE ON. There are differing schools of thought on this because a large table can take a lot of memory when using this option because VFP tries to pre-load as much of the indexes and can actually slow down the query.

4. Use SYS(3050) to define foreground and back ground memory. VFP doesn't do a good job of determining how much "actual" memory it has available to it and often requests more than the system has. When this happens it leads to disk caching and excessive thrashing of the HDD. Setting the values to lower numbers like 2**22 (4 Mb) or lower can actually speed things up.

5. Look at using the HAVING clause which does post-query filtering and can greatly speed things up by performing a filter on a relatively small result set.

6. Ensure that the TMPFILES=path in the CONFIG.FPW file points to a server local HDD folder.

Anybody else have any ideas or comments?
HTH
//:^)
>I have compaq double processor Windows 2000 server with 700 MB RAM (400 MB used
>actually, remaining seems to be free).
>
>I have 15 W2K terminal server users and
>20 100 MB LAN users
>all they are running single VFP 7 application
>This application uses dbf files directly in server hard disk.
>
>However, the perfomance for large queries is somewhat slow.
>
>How to increase perfomance ?
>
>Is it reasonable to upgrade to W2K Advanced server and use more processors.
>
>W2K server allows only 2 processors, W2K advanced allows up to 8 processors.