General information
Category:
Coding, syntax & commands
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
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only