>In that case, they should be looking at how will Terminal Services perform, not VFP.

Craig, slip into your asbestos pants... your answer is fatuous!

Last year I rewrote a significant portion of a User interface to optimize it for Terminal Services.

Briefly, the original implementation built a flat file, from many tables, that was then used as the source for a tree view control. For states with small numbers of items (a few hundred) this strategy was fine. But some states had thousands of items and it was taking up to a minute to build the flat file with the CPU running at 100%. This adversely affected all other TS Users on the same server.

By changing to dynamic expansion of the tree nodes, and switching wherever possible to arrays instead of cursors (to reduce file handle usage), I was able to get the system back to near instantaneous responses with very low CPU usage.

Close analysis also reveals that the OS was doing a poor job of caching material retrieved from disk. One would have anticipated that after the first User (on a particular server) had started the system, that file content would be cached, and subsequent Users would see a faster application start. This was not the case.

Other developers I work with, have noted that displaying complex images, say a bitmap or JPG assigned to _Screen.Picture, can have a major impact on getting the screen, and changes to it (say moving a form) across the wire (especially if it is a remote dial-up session) – one needs to bear in mind that it is not the highly compressed JPG that is transferred, but rather the decompressed version sitting in Video RAM.

So to sum up, you are talking out your butt. There are many issues involved – and in general VFP is well suited to deployment on a multi processor Terminal Server, if some basic rules are adhered to.