Jim,

You must have a very fast network if you can have hundreds of VFP users all hitting 2GB tables, with under one second responses, and still be doing reports, and intensive processes at the same time.

I'm not saying it isn't possible, but in my experience one major processes that have to look at a bulk of the records, and you're dead in the water.

The problem with a generalized statement like I made is that there is always a way to create a scenerio that it is 'fast' and 'works'. But often in the real world, people may do a SELECT * from table and then your network is done.

If you happen to get a user who just enjoys chaos (which is very possible with hundreds of users) then they can hurt you by just needlessly running large reports against 2GB tables.

I've also found that when you get over about 50 million records that VFP can be slow even doing a USE (table)... Just a few months ago I fixed a VFP app that was taking users 5-10 minutes just to get into the program. Come to find out every workstation was opening a 10 million record 'temporary' file when the program launched. Once I deleted and packed the table the app opened right up.

I'd also point out that networks are used for more than just your VFP app. Often you compete with other demands. So large VFP tables pulled through networks can impact everyone if your not careful.

Greg


>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.