>We are trying to get feedback as far as the maximum number of concurrent users that can be supported by the VFP database engine in a real-world application.
>
>Our application is written in VFP 5.0, has 200,000 lines of code, 250 tables, and 1 Gb of data at one of our largest clients. We have found that as the number of users increased past the original spec of 90, response times have slowed down to unacceptable levels (from a few seconds to 10 seconds and more for a specific mission-critical task). At this client, we are running on a Novell server and Windows NT workstations. It appears that we need to restructure our application for client-server or some other architecture, because the VFP database engine will not handle that many concurrent users hitting the same tables without bogging down the network (some past threads suggest that one should consider moving to client-server when one has more than 50 users).
>
>Is there anyone out there who is running a large VFP app with a VFP back end, over 100 concurrent users, and acceptable response times? We would like to be able to support up to 200, and are basically trying to make sure we haven't overlooked any tweaks to the database engine before committing to a major rewrite of the application.
>
>Thank you very much for any feedback.

We have close to 200. Sometimes rebuilding the index files will cause dramatic improvement. How your application is structure will make a difference, ie. are you using views? Are your queries/views fully Rushmore optimized? SEEKS? Mostly new records? Mostly edits? Your network infrastructure can make a difference too.