snip...
>>
>>The speed of your internal LAN would be 10 mb/sec or 100 mb/sec if your are on ethernet and 16 mb/sec if you are on token ring. The fastest speed of the WAN would be 4.5 mb/sec (T3 connection, anything faster like a fiber connection would be considered a MAN or LAN). WAN speeds as low as 56 kb/sec are not unusual. The first thing to do is as Colin suggested. Then if you have static lookup tables move those to the local machine also. Limit your use of grids that do not have some control on the number records displayed.
>>
>>Robert
>
>The program is located on the local drive. Only the data is on the WAN.
>
>The network specialist said the program was only able to transfered 1.5MB of data in 40 minutes. Does that sound right (655 bytes/sec)?
>
>Would there be less network trafic if I used free tables?
>
>Is it even realistic to get a VFP app runing over a WAN at 655 bytes/sec?

The issue is not VFP or free vs contained tables. If the numbers quoted are correct, this is an extermly slow WAN connection. Ask your network specialist what is the speed of the connection. Sounds like it could be 9.6 kb/sec (same as older modems). I don't remember all the particuliars but Foxpro when opening a table does something similiar to the following: (1) sends a 4k section of the index and (2) the first buffer of data. Changing the index then going to the top again (as many apps do in the begining) could cause more network traffic. My experience is mainly in Foxpro 2.6 but I assume VFP works the same. Once the files are open and you don't have grids on the screen (their impact depends on number of records displayed) network traffic is small to retreive a record. The use of SQL would be ill advised in this application. You would want to use native Foxpro to process records. SQL select statements could cause the whole table to be transfered across the network. If you must use SQL try to not create cursors that would cause temporary files. Also the use of relational tables can have a dramatic effect on your application. A few options here would be (1) if the relational table is a static lookup then copy the table to the local drive once a week or month or whatever to keep the data accurate. You could even write a routine to check for changes and copy only when changes to the master tables occur.(2) Rather than using relations design your table as a "flat" file with all data contained on each record. This would open another can of worms but is a good alternative in some applications.(3) If your users can work with subsets of the data (ie. only their customers records) then create smaller files on a routine bases for each user. You could also setup an FTP server and the user could download a "zip" of all his/her data then work locally on their computer. I have an application running this way, it has its own set of problems but they are managable.
In my experience native Foxpro is not an abuser of network resources if used correctly. As an example I had the following senerio:
1. Foxpro 2.6 app running on network.
2. All data and code stored on network.
3. Data entry screen with data from 8 tables displayed.
4. When the record pointer was moved in the main table the program did a seek then scatter memvar on the other 7 tables. Based on the main key.
5. All gets were then refreshed.
6. Total of 55 fields on screen.

7. Lotus 4.0 running from the network.
8. Token Ring network.

Moving the record pointer in the Foxpro app (with all the processing required) caused less packets to be tranfered than moving the cursor from the top of the screen to the bottom in Lotus.

I wonder if client/server would be a good option for this app? Colin...

Good luck on this one your going to need it.
Robert