>Thank's for your detailed respond.
>In my case I have two dozens years till the biggest table will grow to 2 GB.
>I dont see problem with speed, we using with index seek and btw I realy dont know why I see 100 mb ram on task manager when I retrieve data from 350 MB.
>

Just guessing, but, when you seek a record that is Rushmore optimized, only the CDX is retrieved at first. Rushmore then creates a bit map table for the optimization. Then the Seek is performed against the local bit map index. If a record is found, Fox grabs the record from the server. As it was explained to me. This is how Rushmore help in the speed optimization.

I may be off with the details, as I am often shown. but the general idea is there.

If you do not see a problem with table blot, then you can relax a bit. It would still be a wise move to start investigating upsizing the database. If not for the size limitation but for the scalability of the application. Sooner or later, the clients are going to request features that are best done in another environment; .Net application accessing the data, External reporting, web based application, etc. These are general best if the data is on a SQL backend. Not many third party application are tested/tuned to work with Fox databases.

In my experience, I have seen dramatic access speed when I have move tables to SQL server.

Greg
>
>>>Hi
>>>I ask about company that work via 15 workstations on big VFP database (3.8GB dbc, biggest table size is about 430 MB) .
>>>
>>>The company want's to add another 28 users (8 regular and 20 by terminal clients).
>>>
>>>
>>>Do I have to afraid from anyproblem?
>>
>>The only limitation I can see from your description is the file size. Fox has a 2GB limited on all files; DBF, FPT, and CDX. If you are planning to triple the number of uses, there is a chance that the tables will grow to this max. It would be wise to start considering upsizing the database to a SQL back-end. If you can archive and purge older data from time to time, I would suggest it. Most times history data is accessed only for reporting purposes. If this so for you, then the related reports can access the history tables for the archived data. Also, purging old data will help the overall speed of the application. Every time you access a table, via Fox commands, the entire table is sent to the user. With large tables this can take a while. As the tables grow, the application starts to appear to be slowing down. I have many times in the past have had to address this issue for clients. They either allow the tables to grow to big, or allow to many concurrent users to access them at the same time. Either will cause the appearance of a bottleneck. Using a SQL backend will help if the SQL queries are peformed as Stored Procedures or as SPT will help with not dragging the entire table down each time a table is queried or updated.