Hi Bret,

A few things that comes to mind:
1. Make sure you have no SEEKS of empty strings i.e. "". We've seen this
to cause the app to slow down to a crawl even on a small table.
2. We changed the rowsource for our listboxes to use local views instead
of directly to the table. It seems that on NT networks, going up and
down the list can be very slow since it seems to be polling the source
frequently. We did not have this problem on a Novell network.
BTW, This is more apparent on a 10BaseT network connection.
3. Check the thread on slow network performance with antivirus protection.
A lot of people seems to have had this problem where the antivirus
software was slowing down the loading of the app specially for other
users who logs on after the one user has logged on.

HTH,
Arriyel

>>I removed the deleted()s. Performance is a lot better. Thanks. Any other ideas of increasing performance?
>
>There may be others here who know other things to tweek. Those are the things that came to my mind immediately when you indicated that there was a Network performance problem.
>
>I still struggle with the best way to set up a table and its indexes in order to get the least data to travle across the wire, while getting the user all the data that they require.
>
>One other thing that came to mind is to Use composite key expressions instead of multiple tags on required fields. Basically if a person can query on ZIP and State, then create an index on ZIPState. The combining of the two in that order will reduce the data that is brought back because it will reduce the set of records greatly by just the zip.
>
>The above really points out that you need to know your data and is distribution. Also by what methods and fields your user will be trying to get to the data.
>
>HTH