>>How scalable is an applicaiton when all processing for all clients is done on one machine (such as a terminal server)?
>
>Scalability is initially handled by the amount of memory on the server and the processor power. I am not sure what the exact figures are but when planning you should allow a certain amount of memory per anticipated user and scale the processor power in this method as well. When you reach the capacity of one machine it is necessary to place another into service and begin imaging. In other words you would have 2 servers with the exact same configuration and the users would be divided between them.
>

You can spread the work among multiple servers, and each server can accomodate more than one processor if the motherboard allows for it. I've used some fairly large server farms with WTS/MetaFrame, and I've generally found that I run out of bandwidth before I run out of processor/memory resources, assuming that I curb VFP's appetite for RAM using SYS(3050). Without explicitly limiting VFP's buffer size, it'll eat into swap file space fairly quickly. My experience has been that Win2K WTS/MetaFrame is more stable than NT/MetaFrame where the primary hosted app is written in VFP (VAM and some warehousing/logistics apps I've written in VFP6, in small to medium sized environments with 10-25 simultaneous users.)

>>How do applications that run under terminal server fair when constructing and printing reports?
>
>I haven't noticed any degredation as far as report construction and printing (other than the data manipulation issues mentioned above).
>

It's important to strip out the printer-specific information from FRXs to allow for different stations having different default printers (it's fairly common for each different terminal to have it's own default printer, so embedded printer specs can make trouble), and wrapping form updates in LOCKSCREENs to minimize form redrawing is helpful - the form is redrawn only once at the client when the refreshes take place with thisform.lockscreen = .t. before the first, and reset to thisform.lockscreen =.f. after the last. Some sites have had problems with BITMAP=OFF under VFP6 SP4, esepcially with complex forms; we haven't re-enabled it with the SP5 runtime upgrades yet to see if it behaves better for us. Plenty of bandwidth makes the BITMAP=OFF setting less important; forms with lots of busy controls, like Grids, tend to suffer the most from bandwidth issues.

>>The language for application design (DLL's EXE's) will most likely be VB. Would Fox be Better, Worse, or No difference.

Both VFP and VB have their places; the UI elements of VB, using native Windows controls, tend to need less bandwidth to update, since more of the work is handled by the client offloading some of the control rendering to the client. VB native controls tend to redraw faster since they're rendered client-side and will require far less information to update - sending the letters 'ABC' will occupy less bandwidth than their respective bitmaps, and even less so than the bitmap of a form with just those bits updated! Reducing the bandwidth needed to update the UI is critically important when you are bandwidth-limited - far less an issue when linked over a 100BaseTX LAN or T1 line than over a 28Kbps modem dial-in. The busier your UI, the more critical the thin-client bandwidth issue becomes; if you anticipate a plethora of forms, each with scads of pageframes, embedded grids and menus, where users will bitch if they need to wait while the form redraws as they scroll through a big grid, it's not something I'd suggest. If it's interface is relatively unbusy, transaction-oriented, needs to be accessed at lots of sites, all of which have reasonable Internet bandwidth, and you're willing to invest in installing and maintaining a central site and supply centralized administration of the server environment and the necessary connectivity (or will pay someone to do it for you), it's a capable solution.

Some places I've used it - a multi-site customer order-processing and fulfillment business, a multi-location medical practitioner's office, the main office of a manufacturer's representative business (the sales force takes orders and checks fulfillment on the road), a multi-site lending library and a small accounting firm running VAM, where each accounting client does their day-to-day accounting on the accountants' system; each client runs the same VAM accounting package as a separate company. The accountants' central site offers system redundancy, reliable data backup, access from multiple locations, and timely accounting services from their main office.

With VB, the bandwidth issue perhaps is less of an issue; VB apps seem to bog down with lots of controls and forms active anyway, and VB does not offer the native data-centric command set that VFP offers; in many cases, there's plenty of bandwidth between the MetaFrame system and the data (it may even be local, or on an extremely fast backbone between the storage and the MetaFrame environment.) Considerations regarding where to locate temp files (it's advisable to assign this per user via separate CONFIG.FPWs - I manage this via a launcher that builds the CONFIG.FPW on the fly before launching the VFP app, and pointing to it using the -C command line switch; I can assign an appropriate resource file and TMPFILES location based on the user environment before the VFP app itself launches; I do not use a VFP app as a launcher, so that I can freely update the VFP environment, including the runtime, before the app is started.)

>Existing programs are Fox DOS and VFP 6 SP3.
>

Both run; I suggest upgrading to SP4 or SP5. I know that Y2KFOX/DOS will run under WTS/MetaFrame; it requires a bit of playing with the .PIF to get the memory set up right; the exact settings depend on the version of FPDOS, since different versions have different memory managers, and there are differences between Standard and Exgtended Edition AFA memory configuration.

>It really shouldn't matter what products you use to develop the applications other than using "the right tool for the right job." Problems have been reported with the way FoxPro handles and writes forms to the screen. The only problem I have had is when I used the BITMAP=OFF command. Otherwise everything runs fine.
>

I've also had problems with BITMAP=OFF and SP4; I have not tried it under SP5. Low bandwidth WTS performs poorly with VFP and busy forms.

>>I want to lean toward not using Terminal server or Citrix. I have 0 experience with these products. Therefore if it is better to use them I want to use them and throw out my feeling.
>

The old Citrix based on NT 3.51 is not an option with VFP 6. I recommend WTS/Metaframe based on Win2K Advanced Server.

>Citrix and Terminal server work pretty well for bandwidth hungry applications across a WAN. They are a half decent solution but add some complexity.
>

Again, they're a lot better than trying to RAS in and share the files across a WAN, and tend to require less reworking than to re-engineer to a client-server environment. Administration and the initial investment in infrastructure are the two most immediate issues; WTS/Metaframe is not a cheap solution done right, with UPSes, redundant hardware (fault-tolerant systems (including power supplies, disks and if possible Internet connections), clustered servers, and adequate bandwidth. The situations I've seen fail have been where someone decided to cheap out the setup, and paid in down time when critical components failed and were not handily replacable - if the WTS server fails, everything is down.

An option is to go to an ASP (Application Service Provider, someone who hosts a WTS environment for you, in the sameway an ISP hosts a web site), and have them host your WTS-based application for you - they provide the server farm, storage, connectivity and central facility; you pay for access to their WTS system, a fee for disk storage and backup services and provide your own site's connectivity to link to their system (typically, an Internet connection such as ADSL or a T1 service). I work with several competent providers; they have the hardware facilities, in-house expertise, spare parts and on-call service staff to offer the reliability gained from a large, fully-configured MetaFrame installation; they charge a monthly fee for your disk storage and access to their servers, and furnish the infrastructure and support staff as a part of their package service. They can also provide the connectivity for your site, either a direct link like a T1 line, or VPN over various types of Internet connections. It's one way to evaluate whether such an environment makes sense - contract for several months of service with an ASP to evaluate your app in this type of environment. You can continue with the ASP, decide it just doesn't work for you if it's not good without having purchased everything, or decide to get your own facility if it works well and the cost seems more attractive than expanding your initial relationship with the ASP.

One local vendor in this area is www.connectcomputer.com - they have a demo MetaFrame environment you can access from their Web site. NB: I have a business relation with them; I do contract work customizing VAM and custom application development for them, as well as consult on a variety of other automation topics.