Arnon,

I used the number 250-350 because that's the size of the system I last worked on (Netware 3.x and FPD 2.6). That was a "good-sized" environment, I felt.
Yes, I suppose one could use multiple VFP server instances, but I guess I'm more concerned with a "rough number" of terminals which could be supported by a SINGLE instance of a VFP server with moderately heavy D/B duties.

I think it is a shame, by the way, that VFP does not have a clean/fast way to talk *DIRECTLY* to other VFP sessions FOR DATA ACCESS PURPOSES.

regards,
Jim N.
>> One thing that struck me is that one *probably* has to use ODBC to pass
>> table record sets between processes, EVEN FOR VFP-TO-VFP. Am I missing
>> something here - that is, are there ways for one VFP (client) to
>'request'
>> a set of records from another VFP process (server) on another machine
>USING
>> STRAIGHT VFP COMMANDS???
>
>well, you can use VFP tables to create a queue for jobs and have the other
>VFP
>process scan this queue and create the answers in other tables etc.but then
>you
>a. don't use OLE for that
>b. can't use remote views
>(so what's the point (s))
>
>> The other thing that I wonder, regardless of the answer to the above, is
>> would performance/response be tolerable if there were say 250-350 client
>> machines all processing with a single VFP Server. Also, in this
>situation,
>> I *ASSUME* that OLE and other functionality "takes care' of keeping track
>
>> of sender/recipient and that VFP Server need not concern itself with
>those
>> duties. Would that be a correct assumption?
>
>why use a single instance of the server for more than 250 users?!
>
>Arnon