Hi Rick,

>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...

We were discussing the value of objects and collection as a carrier of data. This applies to both outlook and ADO.NET. The point is that working with collections and objects to get your data is extremely cumbersume as the Outlook model clearly outlines: To slow and too inflexible as there is no DML to get and analyze your data. Whether the data is stored in ADO.NET or a proprietary objectmodel in outlook does not matter: They both lack a DML.

>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...

Sure, and I've seen that up to a certain point it does no matter how much data you retrieve, the process memory stays they same. At this point VFP is flushing its cursors to disk.

>>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.

I respectfully disagree. Once the data is in collections, you're are on your own to get information out: There is no DML. Sure you can write classes and functions to help you on common tasks, but it will never be standardized and as flexible and reliable as a DML like SQL.


>>I don't think 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.

Sure SQL experts can do a lot on the back end, but that does not say that those types on functionality really belongs there from an architectual point of view, nor does it ensure enough flexibility and performance.

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

Well a lot of people come from the VB, Delphi, C/C++ world where they don't have any experience with a local database engine. Talk to people who have been developping ERP/ERM, data analysis software and you'll get another picture. Your point may prove that .NET is an atractive platform for development that don't require tight local data intergration. IOW you can conclude nothing on the observation that it is not a much heard argument (Aside from the fact that MS staff has already admitted this).

>>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.

Missing the point. It is not about xBase: It is about local database engines with a reasonable DML.

>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.

And it has been picked up. VFP and xBase are by far not the only software solutions that use a local database component or have a tight data centric implementation, but you'll find that this the area that is much less known to the broad public. It is the area of big information systems which hold and distribute large amounts of data in heterogenous systems. Look at the mainframe and mini applications used in healthcare systems. Check out software packages like SAP, BAAN, NAVISION. Look at accounting packages. Even just look in the data centric function in a reporting tool like crystal reports, crystal analysis, Cognos etc. They are examples of systems that might escape the notion of .NET developers because they are working at the low (front) end of data information technologies. If you subscribe to a hardcore database magazine (DB/M - dutch) you'll see much more of this world of data and scalability. The intended application of .NET, VB and delphi and truly data centric development platforms are totally different: They have database connection, but no database integration.

The tendancy is that the truly data centric systems are getting cheaper and cheaper and now are affordable by medium sized business. This trend will continue in the future. The problem of VFP is that it is a bit of both. Not really a high level framework, nor a low level front end solution.

>I don't buy it...

Its a free country.

Walter,