Well if it worked ok locally then we can be sure that its the network causing the problems.

Maybe when you break the big table down you should try to get the most often used componants of the data into one file. Then break the other files down according to some logical grouping suitable to the application.Try and get everthing you need for that SELECT into the one file though.

I think you should avoid using lots of fixed relationships when retrieving data since that could give you a performance hit on a slow network.

Instead use fixed relationships only when unavoidable and use the seek command to look things up as they are needed.

That should save a lot of overhead when you move the record pointer around in the main file.

This would work especially well with the tables you use to store your memo fields in.

You could consider writing a simple function to return data as appropriate to save yorself coding lots seeks and selects etc everywhere or use the LOOKUP command and specify it is to use an index.

Good Luck


>Nice :-))))
>
>1. First paragraph: tested, went OK.
>2. Second paragraph: tested, ping server: Average round trip: 10 ms - conclusion: went OK.
>3. My opinion at third paragraph: if an elegant approach isn't possible, I have two ways: migrate to an SQL server or splitting the big table in a small parts - nobody will see this...
>
>Thanks a lot for your help, but I'm still open to other ideas...