>I know that the server is underpowered, but that is what my customers are working with by and large. I suppose I should rephrase my question to - can VFP still be used for low end vertical market applications that generally run on peer to peer networks and are used by non technical people? What are the requirements for adaquate performance on a network?
My opinion is that it depends on how willing you are to sacrifice performance on either the 'master' station (the one that hosts the files) or the other client stations. Something has to provide file services for all the other stations' file I/O requests, and VFP does file I/O for all of its database operations.
Location of the shared files may run contrary to your first idea. The files should reside on the least-used system. This means that rather than the files being local on the machine most likely to look at them, the files are positioned on the system least likely to be busy doing something else.
When assigning hardware, the system hosting the files should be the biggest, baddest boy on the block - lots of RAM, fast processor, and a solid I/O system that imposes as little load on the processor during I/O as possible (busmastering SCSI, or at least busmastering IDE with the disk being used for the shared file system being on a separate IDE channel.) No Active Desktop, NO GAMES. And a UPS and tape backup unit.
Coupled with the above, it means that the newest, fastest box should be put in place on the least busy person's desk. You can imagine how well that goes over with an under-educated client. It's often an easy sell - the least busy desk is often the boss.
I've run VFP apps in small peer to peer environments with a fair amount of success (small meaning < 6 or 7 stations total, with light usage.) And I warn everyone that in spite of the fact that it's the biggest, fastest box on the net, performance is likely to rot there when everyone else gets busy.
Performance is going to suffer badly on all stations whenever the 'server' gets much foreground loading in any case, and I wouldn't want to be running a time-critical app with more than 8 or so stations total, even if you don't suffer for bandwidth. And bandwidth is an issue with VFP, especially when doing non-Rushmore optimized queries, because data has to pass over the wire to process the query. If lots of people are running reports or doing non-optimized lookups, the wire gets loaded heavily.
At some point, it becomes a good idea to add an additional system to be the 'server', even in a peer-to-pper environment. That server may not be running a server OS like NT Server or NetWare (Win95/98 will do if necessary) but it will never have any significant foreground loading. Since foreground loading won't be hurting everyone else, you can expect to have a better average level of support.
>
>My app is not that complex - though it will have a total of almost 100 tables in it by the time of completion. The rows in the tables generally are quite small though several may eventually number 100,000 rows or more. The current dataset I am testing has no more than 25,000 records in any 1 table.
>
>One thing that really bothers me is that I have a listbox class that changes color when it receives focus and then changes color back when it loses focus. I do this on all input boxes so the user will know where he is. When the screen comes up it sometimes takes up to 5 seconds before the listbox changes color. This is after it takes 5 seconds for the screen to come up.
