Hi John,

I think the real trouble in IT is that people are just picking up buzzwords following the 'loud GURU' and don't think how this all fits in their own thinking. The big problem of such people is not that they don't have skills in 24 tools and languages, but that they totally lack any vision, intelligence and critisism.

Even on MSDN their are a lot of articles saying how to do something in a particular language, but fail to mention why you want or have to do it that way. I doubt that I would find any documentation on MSDN discussing why you have to use the SQL server to do the datamunging for you instead of doing this in ADO.NET because ADO.NET fall short in this respect.

Of course people doing straightforward data access won't have much problems with ADO.NET. I respect that. However I get annoyed when people trying to tell you what is best for YOUR applications based on arguments of their own limited experience with the tools and application development methodologies they use. Of course when you highlight this in a forum like this and tell the people .NET is not ready for efficient data handling you'll be accused for not having real life experience with the tool. Say what ??? Does anyone saying that have real life experience in writing assembly? Why not using assembly then? It certainly is the most flexible development language there is? Oh... of course productivity ...... I see. Well those guys had arguments of writing classlibs for regular functions missing in .NET. I do not see why this cannot be done in assembly either ....

Of course the real issue which development tool allows you well designed, extensible applications with the least number of (complex) user defined classes and functions.

The fact is that ADO.NET is far inferiour to the VFP database engine: In VFP you have far more control over data than with ADO .NET out of the box. What only takes one or very few lines in VFP (out of the box) could take up pages in .NET (out of the box). A much heard defense is that you can write classes to write the extra functionality. This is really a BOGUS argument: it really does not cut it. I can write classes in C/C++ for that matter too. The problem with writing your own classes is that every single developper is trying to invent the wheel again, most often resulting in very limited, slow and buggy solutions. Imagine what it takes to write a .NET class that takes a string containing any SQL-92 compliant SQL command and runs this on ADO.NET data. Well go ahead. I'd rather use VFP, most often solving data related problems in a single or very few lines.

At least MS now has admitted that .NET needs to be improved in the data area. However, I'll have to see how they are going to do this.

A lot of people promoting .NET as a succesor of VFP are not able to look at the difference and know where to place the tool from a technical point of view. And of course the motivations are seldom based on technical arguments but more on emotional (FUD) and strategic thinking. Rick Strahl is one that seems to recognize the difference between the two. He really seems to have a good technical argument here since .NET clearly is stronger in WEB development. He also recognizes the shortcommings in .NET in respect to handling data (though I don't regard him as a GURU on this area). In my eyes, Kevin McNeish has moved on to .NET for strategic (financial) reasons, not so much for technical reasons. .NET certainly has a bigger market and developping framework solutions and provide training for .NET is certainly a big opportunity. I can't blame him at all.

Anyways, people should realize that if a tool is different than another there likely are advantages and disadvantages of using one tool over another. Whether it is technical or commercial. People should not take everything for granted what they have been told, but should validate statements themselves. If you are not able to validate statements of others, your not able to be a good developper.

Walter,