>>
>> >>>In FPD I used to use pc anywhere that refreshes the clients screen, but
>> this does not to be workable anymore in a GUI environment,
>> >>
>> >>I use Remotely Possible 32 from Avalan and am happy with it.
>> >>
>> >>chris
>> >
>> >Arnon, Luiz, Craig and Chris,
>> >
>> >Thanks.
>> >
>> >If I read you, I must conclude that my hypothesis is wrong. That C/S, by
>> sending only the request to the DBMS and receiving back only a cursor of
>> data is no cure for the problems as I explained them to you in my request
>> for explanation. You seem to imply that the way Foxpro handles that over
>> communication lines to and from a (then) file server cannot be markedly
>> amelioated by implementing C/S.
>> >
>> >Puzzling.
>> >
>> >Thanks again and regards,
>> >
>> >Marc
>>
>> Well, the answer is...it depends. How much data? And
>> particulalry...indexes, which is what will be transmitted for the
>> searching. And when the desired data is found, how much will be
>> transmitted. Do you want to see a list of all clients? Then the entire
>> client table has to be tranmitted? Are you looking for client #34582? Then
>> the index is transmitted...followed by the data. Then, when you want to
>> find client #634232, the entire index is again transmitted...again followed
>> by the data. The choice to go C/S really differs for each circumstance.
>
>Should the entire index be transmitted; or should it only be the index
>nodes to get directly to the correct record? And can't you transmit the
>table in chunks, giving the impression of an immediate response while
>the rest of it is loaded in the background?
>
>/Paul

That's one way. Ultimately, there are dozens of solutions available for any type of remote/ODBC access to give th user the impression of a faster response.

Another method that I've used in the past is to maintain copies, or skeleton copies using keyfields and maybe one or two identifiers, of certain tables that are relatively static locally. That way much of the data cruncing is done locally and the request to the remote search is significantly limited in scope. The local table(s) can be updated according to a planned scheduled download depending on the frequency of change, quality/speed of transmission method, etc. This solution is not always practical and many times must be used as a hybrid to other methods, but it's just one more idea....

HTH