John,

>1. When I issue the USE command to open my parameterized view, exactly what portion of the table/index is transferred over the network from the server to the workstation?

If the query is not rushmore optimizable, the whole table is going to send across the wire. If there are indexes which rushmore can use, only a portion of the index file is send trough the network (the index nodes used to optimize the query and a portion to locate these nodes from the root). The index nodes determine which records of the table are going to be send across the network.

>2. When I issue a requery() after changing my view's parameter, does the entire table transfer from the server to the workstation, or just the one record I'm requesting? I would think that since this app is not client-server, the entire table would have to transfer each time.

Again this depends. When rushmore is at work, the same mechanism as using a table is used (see 1.)

There is also another thing that plays a part in here. the OS buffers some portion of tables and indexes on the workstation. If the source tables and indexes are not changed during a session, the requery doesn'r adress the file server, but get's the data from the OS buffer, dramaticly improving performance.

Of course if you're dealing with highly dynamical tables the chances are that the requery has to adress the file server more often than in a rather static database. Then it might be better to make copies of the dynamical tables at regular intervals and use these for reporting or other purposes (like this is recommended in database server environments) so they can be cached at the OS level.

>3. When I issue a tableupdate(), does the entire table transfer back to the server or just the records that I have updated? Since there is no intelligent app on the server, how does VFP manage this update?

Only the records that are updated are send to the file-server. However, for local views, VFP has to locate the record being updated. Again if you don't have an index (like a primary index) to speed up (internal) locating the record, it will probably first the whole (or at lease a part of the) table.

Index usage is the key to improve your performance. You have to got enough indexes to get rushmore to work, but be carefull not to add useless indexes.

An index has to be highly selective in order to get maximum performance, meaning that one indexkey value adresses only a small portion of the table. For example a timestamp or primary key is highly selective: one particular value only adresses one or very few records. Gender on the other hand adresses large portions of the table (Male, Female, Don't know, both ;-)) Another example of a low selective index is the INDEX ON DELETED() tag. Avoid low selective indexes, because they don't narrow the resultset enough and have the disadvantage that rushmore HAS to use the index, so large amounts of index nodes are transferred from the files server to the workstation.

Don't be fooled by the 'full optimization' goal. Sometimes it's better to have a partial optimized query than have it fully optimized.

Walter,