>I just answered your inquiry, as to why VFP is not a .Net tool? If your logic is that, what's happening with current and future technology does not spells disaster to VFP, fine with me. Mine is that, if it will stay as non-.Net tool, the lean VFP crowd will become leaner long term. VFPers and IT Managers attending .NET seminars and played with VS.NET BETA 2 or even BETA 1, have second thoughts continuing with VFP. Programmers tends to look at futuristic tool. Before, we always fought that VFP is better than VB, and I was one of the enthusiastic individual. Today, it's a different scenario IMO...

Not every application needs to run under a browser and connect to a remote server and then transact with that server using ADO or XML.

There are a bunch of companies out there that need software to manage their operations on a LAN or WAN. There are a lot of companies out there that don't need (or want) a DBA (even!). They event contract their web space to third parties.

The thin client now is a 30 to 70 MB install. Many VFP apps are smaller. So another question might be: WHen is the thin client really thin <g>? So - a simple service to connect LAN/WAN VFP application to remote services when the situation requires, is all that's needed, right! We got SOAP and webservices. Isn't that enough?

The days when every company needed a VB/Java programmer to script a pop-up Commercial on the old home page are behind us. It's time to get back to basics - and just engineer good solid (and hopefully, sexy!) VFP LAN/WAN desktop applications. Maybe we get lucky, and that "one time" project will have a larger market. The Web is just another resource for our APPs, (and) not the only reason for writing VFP applications.

Did I miss the point?
Terry