Hi Tom,

>Some thoughts:

>With a 100T Network and a 20 meg file with n users, opening a table within 2 seconds sounds reasonable. In all likelihood as a table grows it will take more time to open. With even a few users doing things such as “end of the month close out”, things can be slow on even a well-designed system.

uh.... 2 seconds for opening a table is not reasonable. There is definately something wrong here. Even on a 10 Mbps network it should open in only a fraction of a second. Soem thoughts.

1. such delays are common on large tables when the dreadfull INDEX ON DELETED() is used on a given table because when opening the table and SET DELETE ON is in effect, rushmore demands all indexnodes of that indextag to be downloaded before the opening process is complete. So if, you've a INDEX ON DELETED(), get rid of it.

2. Another possiblity is having virus scanners that delay opening of files. Make sure you turn them off.

3. When dealing with a table that is part of a database, you might want to make sure that noone else has made changes to the database (files, not the tables). If changes are made to the database files, the oplocking mechanism of the server hosting the database files turns off read buffering. This means that for each client using this database that database definitions are traveling accross the network each time you open a table or view. This can cause big delays, esspecially on slower networks. Alternatively you can avoid the problem by making the database read only in the production environment, so that each client can (read)buffer the database files.

4. Make sure the table is found directly in stead VFP has to search along the PATH settings. a USE MyTable might be slow because the VFP has to search the location of the file. a USE data\Mytable is faster because you directly tell VFP where the file is stored. a MyDatabase!MyTable should be as fast as well.


When not dealing with the situations above, at the VFP side, the time to open the table is depending on various factors:

1. The width of the table (the number of bytes to read from the field definition header).
2. Whether a memo/general field is used in the table and thus a .fpt file exist for that table.
3. The number of indexes on that table (number of bytes to read from the .CDX file).

These factors all have to do with bandwith. AFIAK when opening tables, VFP only loads the first few records (or (k)bytes) of a table until a command demand the read of more data. Therefore it can be that tables which are smaller than the default amount of data read when opening tables open much faster than larger tables. However, this 'buffer' is small (I do not know how small and how it can be affected and if there are factors which influence the size). For most cases the size of the table has nothing to do with it. A 500 MB table should open just as fast as a 5 MB table (if they've got the same table structure and indexes).

Walter,