>Hi Rick,
>
>You mentioned that "VFP's learning curve is no less than .NET". I have no experience of Net and definitely wish to get your opinion on this subject. I've read your web book and that was a delight to read the stuff...

I'm talking from a new user perspective. VFP is very powerful, but if you throw it at any new user - especially those coming out of college or having programmed with other languages like VB or Java before - you will probably find they will be somewhat confused by VFP's odd mixture of OO, Data Language, internal functions etc. Don't get me wrong I love VFP and I continue to use it on a number of products day in and day out in addition to .NET, but if you look at VFP from the outside it's an odd language. It takes time to understand this particular model and to really be proficient in VFP is a long process just like it is for .NET.

>Do you really feel that the Net stuff can provide a progamming experience that matches the way of doing things of the typical vfp analyst in terms coding but learning, testing, refactoring and quite a few other time-consuming tasks?

No. 'Experience' is a very subjective term and if you compare things from a VFP perspective without an open mind you will be very disappointed. Things that are easy in VFP take more work in .NET. The most obvious one is the ability to directly use SQL in your code with VFP expressions.

However, if you are approaching things from a framework approach - especially when working with a remote backend like SQL Server - then you probably weren't doing stuff like this anyway. In that case you likely were using business objects that abstracted SQL out of the business layer into a ata access layer. If you've done this in the past, you will find that the .NET way of things will be very similar.

Yes .NET takes more code to say run a SQL statement, but I never use the raw data commands - it always goes through a business layer. So whether I'm in VFP my data layer eventuyally boils down to a loData.Execute( lcSQLCommand ) (or related methods for non-queries, stored procs etc.) The end result is that the business logic code in VFP and .NET looks nearly identical. The big bonus in .NET is that you get the whole .NET framework which covers so many thing that VFP does not natively. You can do most things like this with VFP but you have to figure out different interfaecs - some COM, some API, some WMI etc.

My main point if you compare .NET from a pure VFP perspective and only view it as "I want to do exactly the same thing I did in VFP the same way", you'll likely be disappointed and say 'it stinks'. But if you can see how things are done in .NET and take advantage of the features there, you will be rewarded with a much richer model to do almost everything with control at every level of the framework.