Tom,

>Now in the .NET environment I see the following things needing to be learned:
>
> C# or VB.NET - replacement for VFP language
> ADO.NET - replacement for VFP cursor

Errr, replacement ? why ? VFP isn't going anywhere anytime soon. VFP has got some very unique characteristics when it comes to data handling. VS.NET is not going to change this. It is my honest believe that if you're looking for ultimate power off a dataengine VFP will be unbeatable for a lot of years to come. Maybe if you don't require a powerfull dataengine it may be an alternative, but why should you, if VFP serves you well, why abandon it ?

> Crystal Reports - VFP includes a report writer

This has nothing to do with VS.NET. CR can be intergrated into VFP very much the same way as with VS.NET.

> SQL Server/Oracle - you can get by with VFP local DB engine

As I posted before, If you're thinking that SQL-server /MSDE/ORACLE can replace all the characteristics and advantages of a the VFP engine, dream on. First of all the VFP engine is free, freely distributable and very lightweight. Further it has no DB limit and scales up to sevaral hundreds of users. Also, some of the xBase record oriented commands have no equivalent in set oriented DBMS like MSDE. If you're fond of optimizing applications by using good old SEEK(), KEYMATCH(), SET FILTER, SET ORDER TO, SET RELATION, SET KEY TO etc, you'd better think twice before throwing away the VFP dataengine.

Johns, mistake is that he thinks that VFP has no characteristics that have an advantage over VFP. He clearly underestimates the power of VFP in the data arena. Futher he ignores the tremendous investments in code (e.g. frameworks) people have in VFP. Well go out and throw it all away ! Unless, maybe like john, you don't have invested much into code and frameworks.

Of course there is still a lot to do in VS.NET to become what Microsoft says it becomes. Also we've to wait and see what the competition has to offer. Maybe well be developing Delphi (kylix) on linux in about 5 years. VS.NET is not out yet and the early adopters of VS.NET will likely have more problems working with the product than those who can sit and wait and make that decision when a bit more is proven.

John can yell and shout, but as long as there are no compelling, interesting products and competative (in your branche) products written with VS.NET, nothing is proven. I like to remember you of OS/2 which was technically superiour over Windows 95, well we know the story about that.

Walter,