>>>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.
>>
>>Craig
>
>I was kind of referring to a typical, modal application, where you could have single seeks as well as massive extraction from the DB. Most of these applications have both. But say you want to check for the existence of a key in an index, I guess there would be a lot of going back and forth over the lines in native VFP, whereas in C/S you should have better response times if your communication lines are the bottleneck.
>
>Now if you tell me that in your experience and for small application (max 20 users and a DB < 50 Meg), the differences would be negligeable or even in favour of VFP, then I'd thank you (which I do anyway!) and forget all about C/S.
>
>Regards Marc.

No problem...that's what we're here for.

Craig