|
We wouldn't recommend to migrate to SQL Server if the size of your largest table is less than 1 gigabyte. The nominal productivity of the local network is 100Mb/s, the actual productivity is about
50Mb/s. Here you should first evaluate available resources and plan development costs.
Consider typical amount of memory on your computers; try and analyze how much memory is needed for typical
queries of your programs. Just examine how much memory is used when the
query is being carried out. You may monitor this via Windows task manager. If it takes too much time to
perform a query, try adding some (temporary) memory to your computer. The fact is FoxPro optimization heavily depends on the amount of memory. This results in the speed of
query, which may vary greatly. In other words, if you use up all available memory, you'll end up with a slowest application, as optimization becomes unavailable.
It is also useful to analyze
query optimization with the help of Sys(3054) and Sys(3092) functions.
So, we can say that on one computer (or in fast network) VFP data access is faster than the one of SQL Server. The reason for this is simpler technologies of memory allocation, caching and data access, as well as absence of ODBC costs.
If the stumbling block is network productivity, try introducing mandatory buffering with the help of local cursors. Do it everywhere. For example, if your list of clients contains about 100 000 records and you reach it from GRID (or BROWSE) when you work with Documents table, it might be a wise idea to create a local cursor containing indexes pointing to keys and check this cursor for the needed values before you address the source. When you
query the source table, save query results to the local cursor. Try avoiding LOCATE or SEEK commands; use SET RELATION only. Surely, we're not talking of ALL the rules needed to ensure correct operations of RUSHMORE technology.
Practice shows that slowness of FoxPro in many cases depends on the fact that the developer doesn't know (or doesn't stick to) the rules of successful implementation of RUSHMORE technology and thus blackens the good name of this
product. If you have to work with several remote locations (e.g. using modems), you still don't have to migrate to SQL Server. It would be easier to make separate applications for these locations using a simple FoxPro-based Automation server, than to update all the code of your application to SQL Server syntax.
|
