Hiya JimN --

Nope, don't think so (generalizing). Try setting up a remote view or SQLEXEC() to tens or hundreds of thousands of records without some forethought or planning and you'll see what I was talking about.

Data dicing is an artform when large tables are involved.


>
>Aren't you and Mark generalizing just a tad too much???
>
>What if this app. is something they couldn't even do before, and so the users are thankful regardless?
>
>His net transmit speed was darned good! Possibly there is no intention to ever use this app. across a modem, in which case where's the problem?
>
>WWe should remember that all appsw are different and that, until we have some good background on one it is a dicey proposition to criticize it (or even be 'sympathetic', cause maybe no syumpathy is warranted).
>
>Cheers,
>
>Jim N
>
>>Hi Mike ---
>>
>>I don't know what the discipline would be called nowadays (maybe data load balancing?) but there used to be (still is?) a whole subgenre on VLDB (very large database) access and processing theory. I feel for you: It is not easy when dealing with huge numbers of records to be able to pare down the queries and the types of access to properly tune a system.
>>
>>
>>>37,000 records (3.4 Meg) is a very small amount of data as far as I'm concerned. I typically deal with data sources exceeding 700 Meg with millions of records. We do a lot of middle tier data processing using VFP COM servers connected to remote data sources. Some of these servers are launched by user requests via intranet and they return the resulting data set after processing. This reduces the segmented network load as well as the client machine's hardware requirements.
>>>
>>>Mike