Thanks for a good reply, Rick.

It's true what you say that 'easy' depends on what you are confortable with. I have found that by becoming very proficient at a good tool I am more productive than learning superficially several tools. It would be better to become expert at several, of course, but time availability and brain bandwidth are important limitations that tend to freeze you to what you already know.

On the other hand I am hearing you loud and clear that .NET is a tool in which it is worth to become very proficient.

Thanks,

Alex

>>Since nobody can argue about the value of easily building data-centric applications, I want to emphasize that macros are important too. They are not mission critical, but they are very useful. For example, with macros you can build SELECT statements on the fly in a few lines of code and do other things at runtime that give you a lot of flexibility. I hope that Microsoft remembers that not everybody is a corporate developer in the Fortune 500 (too bad) where controlling what developers do may be useful :)
>
>I would argue the case that 'easy' is a very relative term and it truly depends on what you are comfortable with. I was recently involved in a largish .NET project that had some real hotshot SQL guys on the team and these guys were extremely efficient in building the data access code for the business layer.
>
>Not only in knowing the right SQL and language tools to use (and there are many more choices in how to retrieve and return data in .NET than there are in VFP) but also by using efficient wrapper classes that remove the complexity that most people see when thy look at .NET data access code. The reality is, unless you're a junior coder, you're very rarely going to be writing code directly against ADO.NET, but you're going to be coding against a Data Access layer that looks not much different of a data access layer you might be using in VFP.
>
>The difference here too is one of culture. VFP developers like to write raw SQL statements in often the wrong places (ie. not your business layer). If you take a more formal tiered approach to development in Visual FoxPro too, you (the 'greater' you here) would be using a Data Access Layer in Fox too in which case some of that real inline SQL ease gets a little more complex as well.
>
>For me personally I've found that once I build applications with business objects, the code I write in FoxPro and I write in .NET is not all that different!
>
>As far as Macros go I used to think too that lack of dynamic evaluation is a big loss, but the truth is that with .NET you have much less need for macros. For example, you don't need Macros for SQL, because your SQL is done through objects that are completely parameterizable so you can use plain strings to represent thing. This is kinda like using ADO...
>
>Macro usage is handy when you really need it (and you can do it in .NET but it's a bit of work and needs to be wrappered) but just like in VFP it should be avoided.
>
>There are very few places in VFP where I use Macros, and although I use EVAL() a lot it's mainly because of the quirky way VFP needs to evaluate 'function pointers'. Again, most of those cases there's no need to do this in .NET because .NET has real function pointers for example.
>
>There's no doubt .NET has a very large learning curve and getting up to speed is a huge investment - no way to minimize that. But the end result is in many cases more a more flexible development platform. Especially for Web applications...