>What is the realistic upper end of table file size before speed suffers? What about number of users accessing it?

Both of these issues are determined as much by the network itself (bandwidth, server capacity) as by the VFP environment. What works for 25 users with a honking big dedicated server and a well-planned network with users spread across a couple of 100Mbps network segments is very different than what will be acceptable on a 10Mbps EtherNet peer-to-peer network with an underpowered Win95 box as a server running the application in the foreground as well as servicing everyone else.

>Our company did an install for a company that had aprox 25 concurrent users and 700MB of tables. They were a 24 x 6 operation and did a very heavy volume of orders. We could not get the speed of the searches and the reports in VFP5 fast enough to please them.

How are you processing queries and reports? Are the queries optimizable (ie do the queries' select and join conditions posed in a way that matches up with the indexes associated with the tables, or are you forced to pull down vast amounts of data to perform selects and projects before records can be selected?) Where are reports being printed? In the first case, a poorly-planned query or search may involve passing huge quantities of data over the wire; not only is there a delay on the station posing the query, but if network bandwidth is scarce, everyone else has to compete for the wire. Network printers are a mixed blessing, too - a large report not only eats up server capacity, but bandwidth as well. And if you're using printers attached to other people's workstations, how busy their system is, and how much disk space and memory they can devote to spooling print jobs, will affect when the report finishes running on another station.

The probability is that the network or the application architecture is imposing the limits on system performance; doing the application in another language using the same strategies for where the data lives and where it's massaged to service queries. It's unlikely that your application's performance is processor bound.

>Any real world info would be appreciated.