>>> Right now, I plan to become familiar with .NET but wait for better RAD
>>> capabilities directly from .NET or third party tools, while getting
>>> immediate results with VFP.
>
>Interesting points. What parts of the .NET RAD tools do you find lacking compared to VFP's? There are some obvious ones of course. The ease of creating a local VFP database and directly integrate it into a prototype is hard to beat. But besides that, I would be interested in your opinion...
>
>Markus

Thanks for asking, Markus.

When I first got hold of .NET I decided not to be left behind and took a week of training in it. After the training came two months of practice. We also hired a person to master and concentrate in .NET development. However, after 8 months we abandoned the effort because it seemed very cumbersome, not to mention slow when executing. Even though I thought that "the king had no clothes", I decided to keep an eye on .NET, because it would be silly to bet everything against MS.

What was objectionable?

1) Extremely cumbersome data binding to form objects, all in error prone, repetitive code.
2) Creating stored procedures to save data to SQL server and then each time the structure changes having to retouch them. REPLACE is so direct and easy.
3) My style of programming uses and abuses the SQL select which is a breeze to do in VFP and a pain in SQL server. As you know, you can't just issue a command, but instead have to build a command string, which is easy to misstype, and go through hoops to connect, create data sets and cursor adapters, fill them, plus I don't remember what else.
4) Having to create get and set procedures to use properties, for heaven's sake.
5) As far as I am concerned, it is *too* easy for MS to modify the classes. I anticipate that MS will do to .NET developers the same thing they have been doing to the poor VB developers, namely changing the data access approach every other year and leaving people out in a limb. I like the fact that the VFP language is mature and stable and meticulously backwards compatible.
6) Execution speed is very important. Fast machines are not a good enough solution, because they would speed VFP code too. More memory does speed .NET considerably, though.
7) As you said the lack of a local data engine, at least for temporary cursors, is very debilitating.
8) Having simple commands live deep in the classes. If nothing else, this causes very long statements and a lot of typing. I presume after enough time I would learn many of the functions in all the framework classes and declare the namespaces.
9) I hate having to go backwards for quite a while before going forward. It's not worth it.

What I really would really like is to be able to say from VFP "SET DATAENGINE TO SQLSERVER", or "SELECT * FROM xxx ATSETVER INTO LOCAL CURSOR xxx" and then continue using the VFP syntax which is very elegant and readable. Being readable is important becasue it clarifies your thoughts.

In summary, as far as I know .NET data access sucks. However, they continue to work at it and perhaps will get it in version 3, as has happened in the past. Also, I recognize ASP.NET is a nice complement to VFP.

As an aside, I enjoyed Rick Strahl's approach to business objects: simple, practical, with ease of use and mastery as a top priority. I suspect that the MM approach may be too encompassing and rigid. You have to strike a balance between power, ease of use and flexibility.

Your Milos approach sounds interesting, but please don't tease us with vaporware. As you know VFP developers don't appreciate having our tool deprecated because it undermines us in front of our customers. Also, rather than convert desktop VFP apps, I'd like to just be able to extend them easily into the web.

Alex