> In my opinion VFP has only one thing going for it over .Net languages: The ease of of data manipulation. Please note that ease does not make a concept better, just as implied, only easier.

This is a demonstratable wrong statement. From an architectual viewpoint, data is data no matter the layer in where it resides. Data should be handleble with a decent dml on ALL layers. .NET is lacking a decent dml (up to now, heck it does not even closely match the DML of SQL Server) for anyting except the backend when using SQL server, and therefore is inferiour to the VFP model where you can develop applications with relational data on ALL layers.

I do know that this concept of 'data is data and should be handled with a dml on ALL layers' is a new concept to many of us. But think of it. WHY TO HELL DO I NEED TO HANDLE DATA DIFFERENTLY DEPENDING ON THE LAYER IT IS IN ? It is plainly stupidity and the serious lacking of the tools that still have not fixed this very simple, but very important fact.

>For n-tiered development using a business object to SP approach you lose most of that ease benefit of VFP. If you look at what the .Net platform brings to the table versus VFP you will find a long list. It is worth it to develop in c# to me just to get away from the misery that is registered DLLs and .ocx controls which are darn near required to bring a VFP UI into the modern world.

There are a lot of C/S multitier desgins, but the one you have choosen might not be the best for someone else. In fact you're more of less driven that way, just because of the limitations. IN VFP you can have every C/S architect you're using in .NET applications. The reverse is simply not true (at at least not practical).

> VFP is an exceptional tool but it is up against the clock. Albeit no time soon but in the not too distant future 64 bit OS's will become more and more the norm leaving VFP out in the cold. A wise developer will have another tool mastered long before that day comes. That is the choice of the individual developer however. On the bright side, the world needs plenty of bartenders!

I know a few COBOL programmers who refused to move on and earn a heck lot of money. I don't see the move on statment as being absolutely true. In fact everytime you move on, you're on the bottom of the payscale and slowly have to climb up. That does not mean that I personally won't explore the future, but I do realise that when my product is a leader in the field, no-one basically cares what the programming language is.

Walter,