>I'm using Visual FoxExpress 5.0 which offers local views as an option. That makes it a lot easier to go to remote views. (I believe VFE 6.0 offers the same feature.) I chose to use local tables because I was new to VFP and there was so much else I had to learn. I think I made the right choice. Getting up to speed with O-O and visual programming in general was hard enough for me. (Don't learn as fast as I used to.)
>
>JVP, for one, doesn't like local views. What's your POV?
>

I'd love it if every one of the clients I develop software for had the wherewithall to put up a soid backend. I still have an awful lot of sites where the entire environment is a single Win98 box. It isn't feasible to say "no SQL Server, no washee". From the MS product standpoint, until the arrival of the MSDE, there was no locally-deployable SQL Server subset available until very recently. Native VFP table handling certainly has a great deal of speed availalble to it, and I can use native file handling and local views in almost the same ways as I would use remote views. Things where I would rely on SPT can generally be accomplished with the native file system.

VFP native tables and native file handling is fine from my POV as long as other issues such as network traffic, security, journalling requirements and the like don't preclude it. If these issues do surface, the cost of the backend is likely to be far smaller than the cost of plunging headlong into writing a lot of code with less functionality. It's the same reason I bought SDT - I could kludge up some of the same functionality, but it'd cost more, be less well tested, and probably wouldn't incorporate a lot of the features that Doug built into his product. Why have clients pay for me to reinvent the wheel when they can buy a set of Michelins off the rack?

The key is that I develop with the native file system so that the impact of moving off the native file system is minimized. I use a framework developed from Visual Maxframe, and like VFE, the changes caused by moving from the native file system to the server backend environment are minimzed and isolated to a small set of classes.

>Ed R., I'm intrigued by the idea of writing a middle-ware UI-less VFP app that can store data in VFP tables or in an SQL DB. The front-end would be written in VFP but would send the data to the VFP middleware program running under Win2K for storage via XML. The VFP middleware app could run on one of the dual-processor RAID super-machines that you describe. Seems like VFP could store data in local tables much more reliably this way. I might need a separate middleware VFP box for batch operations.
>
>West Wind Web Connection would certainly be useful if I went this way. Any thoughts on this approach in general?
>
It's certainly a valid approach; before committing to hardware I'd want to see where the likely bottlenecks were going to be. There are a number of very strong multiprocessor boxes available now commerically; I've been quite happy with the HP 4 way and 8 way server boxes, which use the Adaptec A133 3 channel RAID controller; very similar to what what the SuperMicro GX motherboards that used the Adaptec 7895/3860 chipset and the ARO1130 RAIDPort controller. I'd also want to look into systems built around the new Intel 840 chipset, and the I2O platform asynchronous multiprocessor implementations.

Rick Strahl could probably give you some definite feedback on what demands a mid-tier needs to meet with WebConnection.