Hi Greg,

I think that you are overstating the issue of table size versus humdreds (more than 20 you say) users.

I've seen sub-second response time with 200+ simultaneous users and several table nearing 2GB, tables and indices and FPTs totalling more than 35GB.

This application did have a RAID5 Storageworks array, but a rule of thumb like you state just feels way too off to me to let it go by.

regards


>VFP works best with lots of records but small indexes and table sizes. This is particularly critical in a network environment.
>
>I have a production planning application that generates more than 14 million records and performance is still good as long as everything is optimized and the table sizes don't get too big.
>
>I've never run exact metrics but I never like to have tables more than 200MB when the number of users gets over 20. If you have hundreds of users on a network then your going to need very reasonable table sizes.
>
>I don't see the 2GB limitation being an issue at all except for possibly web servers and very tiny networks with a small number of users. There simply is no way you can have 2GB VFP tables on a network with dozens of users without severe performance problems.
>
>Another trick is to keep index sizes small when your table sizes start to grow. VFP is smart enough not to pull an entire full 2GB table through the network when you only want a record or two. But it does however need to read the entire index file.
>
>My advice is if you need over 2GB tables in network applications to consider another database solution.
>
>Greg
>
>
>>In the near future is Microsoft Planning to increase the file size of a table from 2GB.
>>
>>Currently the max. limit of a file size is just 2GB for foxpro tables.
>>
>>Lot of times people ask us at the trade show, Can foxpro handle millions of records.
>>
>>I know we have a database table with only 150,000 records init and the size is near to 1 GB.