>That is not entirely true. We are truly considering .NET for our internet extensions, in fact we have already decided that this is the way to go. However for the desktop apps it truly is a different story.

I agree and I've actually followed that same path at the moment. For Web applications, ASP.NET is too compelling to pass up, but on the desktop WinForms is currently lacking. 2.0 improves this a lot, but I still am not sure if it overcomes some of the major shortcomings (large runtime, large memory consumption and slow startup).

>I think I know quite a bit about data. And what I see here (And this has been acknoledged by a few MS representatives as well), is that (local) data access is truly undervalued.

Yes it is <g>. Microsoft is shooting for the Enterprise market (as is just about every other tool out these days) and the idea is that applications - no matter how small are built with n-Tier approaches in mind. In that approach the data management is almost entirely handled on the server.

While I agree with that philosophy for the most part I also agree that the local data support is pitiful in .NET and usability would be drastically improved if there was a better larger amounts of data on the client side and be able to efficiently requery that data. Apparently this is an uphill battle at Microsoft though since several people on teh VS Data team are pushing for this but it doesn't seem to be making much headway.

>First of all, there is no standardized DML available. No SQL, No xBase. If I look at MS outlook with a COM interface where the data is accessible through objects and collections. Why do you think it is so cumbersome to get all the email from a particular sender, the 10 most recent contacts entered. The appointments of today ?? Why do I have to spend a few hours or even a day to program this stuff, why not something like ?

>So could you give me a reason to revert to a technology that handles data and throws me back at least 25 years ??
>

That's a totally different story. Outlook isn't a database engine and Outlook COM is not meant to act like one. ADO.NET is a database front end engine. You can't compare those two things...


>Second, Objects and collections do take process memory. Therefore ADO.NET has a scalability issue when dealing with larger amounts of data on the client (Have you ever wondered why outlook takes 3 minutes before becomming responsive when your pst file is taking half a gig)? Yag is working on making this scalable in future .NET versions, but the only way to do that, is to define a file format so that ADO.NET recordsets can be flushed to disk and not taking up process memory. My question to him was why to stop there? You could define a full spec database engine a'la VFP to solve a lot of issues surrounding data.

Well cursors and records in VFP also use memory. Have you ever retrieved a large result set and checked VFP memory consumption? I'm sure you have...

As I said above, this is .NET's data weak point, but I will argue with you that if you're downloading huge amounts of data to the client there's a design problem in your application in most cases. There are times when there is no choice but in most cases other approaches can and should be used to retieve data in managable chunks.

>>Using Collection is not only logical it's also easy. Whether you use SCAN or a FOREACH loop to iterate through data is that really so much of a difference?
>
>See arguments above. Collections are a PITA and should never be used to handle larger amounts of data. Relational is the way to go. The application should be OO, the data should be relational.

That's your opinion - when used correctly collections are a perfectly logical mechanism to access data.

>>You're stuck in the VFP mindset. This is neither wrong nor bad, but that's clearly what the issue is. Nothing is going to satisfy you unless it matches your VFP user experience... it'll be a long time if ever before alternatives
>
>I don't I'm stuck in the VFP mindset at all. I'm stuck in the data mindset. If VFP development stops I probably end up in doing ERM/ERP, business inteligence, information analysis and exchange, where working with data is far more advanced that muddling arround in .NET. Of course you don't have the great flexibility on a low level, but at least you have the tools that efficiently can handle data in a (semi) relational matter efficiently. Again, My mindset is set to data, not in total control on the low level.

We had this discussion before. I'll be the fist to admit that my strength isn't in data management. But I have seen applications that are built by SQL expert who do wonders with SQL backend code. I'd argue there's nothing that you do with client side cursors that can't be accomplished - efficiently - with server side logic.

If it wasn't so there'd be a lot more people clamoring for this functionality than there are.

>The issue seems to be that the .NET guys for whatever reason cannot / don't want to see, that handling data is a huge step backward in .NET. They fail to see how this fits in the evolution of software at all, missing the the lessons told by date and codd what it means to handle data relationally. They fail to see why OO databases failed. Why SQL (while an imperfect implementation of the relational model) is so important when handling data. They miss the theory and the vision how relational data and OO developed software should be integrated (again see outlook example above).
>
>While VFP is growing old, and surely many things could have done better when they started from scratch now, it at least recognizes the need for such architecture. It might explain why xBase has such a long life. Just disregarding this issue is just plain ignorance if you ask me.


Well, differing views. I don't agree and I don't buy for one minute that the vast majority of developers out there are simply ignorant and missing the 'enlightenment' that is XBase. It's not just .NET mind you - what you're saying applies by the same stroke agains the Java EJB spec, Delphi's database strategy, IBM - this model isn't specific to .NET but almost universally accepted. While I can understand a certain ignorance in the 'big park' if the arguments you make were truly so compelling it would hve been picked up long ago. After all XBase has been around and most database developers around today probably come from an xBase background originally.

I don't buy it...