Rick,

This has been a great discussion and I think we've put it to bed. I hope folks read and learn. Thanks.

>
>>I wouldn't, but I'm trying to be realistic. Often, there's a wall between those responsible for enterprise data and those writing desktops to access that data. Often, desktop developers have to black-box approaches to the data. While structurally this sucks, it's a political reality in a lot of cases.
>
>Yes I know. There's no doubt that it works because it's there is the case in most of those scenarios. But what I'm saying is - and it sounds like you agree - that this isn't necessarily the right way to do things and certainly not the only one.
>
>Many folks around here (including myself originally) whine about the lack of more flexible data access a la Fox, but the truth that there's much flexibility there, but it's different. The feature set is similar but it doesn't work on the same principles and it takes time to get used to those principles. Neither approach is necessarily better, but if you understand the architectual issues addressed in .NET that FoxPro does not then the reasoning for some of these things make sense and alas even become logical and intuitive. As with so many things, just using technology is one thing - understanding it helps greatly in using technology to its best possibilities.
>
>But I'll be the first to admit that to grok that stuff is not easy if you come from an xBase background. Without a good business framework - homegrown or purchased - data access is a pain. With it though - the code you write in Fox (using business objects as well) and .NET doesn't look all that different.
>
>>It depends on the application. I wrote a FoxBase application in the 80's that did intense data munging - it had to take a simple premium payment and then break it down into literally thousands of journal entries based on the insurance treaties in force. Could it have been better if the logic was coded into a data service tier away from the client? Possibly. But I had to live with existing enterprise paradigms.
>
>True, but if you were designing this from scratch today - even in FoxPro, do you think you'd use that same approach? My guess you'd do something completely different today. For one thing back then there was no SQL in xBase and Rushmore wasn't there either...
>
>Still though - I've seen a number of Fox 2.x apps that are real screamers using nothing but native xBase commands - no SQL to be found. But then Fox 2 was also considerably faster at many data tasks than later versions of VFP.
>
>>I do not disagree, especially since SQL Server is pretty smart about re-using precomplied queries and reentrance. OTOH, I go back to my previous point: Sometimes DBAs or other admins refuse to grant you those services and you're forced into doing client side munging.
>
>Well, you're not necessarily forced into StoredProcs. You can send batched commands (ie. 'local Sprocs' <g>) to the server. Works the same way.
>
>> Of course you can do complex data in .Net circa 2005 .... just not terribly efficiently.
>
>Again it depends on what you are doing. If you're a Fox developer writing complex SQL commands to get your data - that's no more complex in with .NET.
>
>The main thing that is not as flexible in my opinion is the fact that you can't re-execute additional SQL/set based commands against your result sets. Once the data is there, you have to pretty much work with an array/collection based structure. This actually has some advantages - it can be very fast on mid sized sets of data for example (but also on the slow side with large sets of data). But it lacks a complex filtering and sorting engine to post process data...
>
>>I feel your pain <g>.
>>
>>IMHO, MS really blew it in the initial design of .Net by not including some sort of simple, integral data capabilities.
>
>
>I agree wholeheartedly on this point and I and many others from the Fox community have pushed the data folks at MS on this point - so much they're sick of us bugging them <g>.
>
>I think the problem isn't on the technical side because the developers inside of MS I've talked to agree. I think it's a political issue and Microsoft being Microsoft that they want you to use SQL Server or SQL Express or whatever and not provide a built in engine that might reduce the need for it.
>
>Fortunately there are third party solutions out there that provide this functionality. Especially VistaDb which provides both ASP.NET providers as well as native API that provides much of the xBase like functionality (these guys used to make Apollo which is a xBase engine for Delphi, C++ and other environments).
>
>>It's not terribly hard to ship VFP data out in a heterogenous environment. We have a pretty good CursorToXML function and people are writing custom stuff all the time for this.
>
>That's a hack solution at best. Yes, it works, but you have to understand a lot of different technologies to make this work. It's not a native solution. I mean - have you ever tried passing data over a COM object? Convert to XML with the cursor adapter, then on the other pick up a STRING (!) turn import it into a DataSet. Talking about comlexity... Same for Web Services - how do you persist an object and publish it through a Web Service? There's no way for FoxPro to publish an object to XML (well, with wwXML you can but even then), much less publish an object to XML without having to write a ream of additional code to do manual mapping conversions.
>
>It's not integrated, it's slow and doesn't provide a native XML or Data datatype that you can pass around easily. Not for COM, not for HTTP transfer and not for Web Services. You're responsible for all of the XML encoding in all of those scenarios.
>
>Is that how you want to write code for a front end distributed application? There's no easy way to abstract that away for a client who wants to consume your data. Add to that VFPs inability to publish a COM typelibrary that really maps your object structure without hacking the type library after compilation.
>
>All of these things are not integrated in Fox, and while you can do all of this it's not trivial. I've been asked for many years from otherwise very smart people how to build a distributed application and get blank stares when it comes to Web and Web Service applications, because quite frankly it's difficult out of the box. There are many choices and many of them are not well integrated.
>
>I know a lot of people write this stuff off as 'not important' because they don't build apps that pass data around, but it's a real consideration for many mainstream business applications that need to be built today.
>
>This is the flipside of the data issues in .NET - most of the reasoning behind how data works in .NET is based on the ability to disconnect and represent data easily in a variety of ways TRANSPARENTLY.
>
>>>>And maybe that's the crux in marketing .Net - you cannot ignore data.
>>>
>>>We agree on that for sure. And believe me when I say that .NET can use a lot of help from VFP concepts. But that doesn't mean that it's not workable or even crippled without them. I think you'd find that if you provided many of VFP's features into .NET many .NET developers old and new would not touch them because they are a non-standard approach to data... as VFP developers we're used to them, but most database developers of just about any other non-xbase data environment wouldn't think of data manipulation in the way we often do...
>>
>>I completely agree with your assessment. I wish I could elaborate further but I can't - suffice to say that anyone reading this would be advised to research LINQ.
>
>LINQ is interesting but I think VFP people will find it lacking. It's not going to provide the kind of data connectivity that we're used to in VFP. The real value of LINQ will be with data structures in general - specifically I expect it will be with business objects. From the stuff I've seen LINQ's data access features look like its weakest link. All the rest of the language features are hot, but as you say Data is the key and that's the part that's looking least fleshed out.
>
>A lot can and will change surely, but I wouldn't hold my breath to get xBase like functionality into the languages - and SQL is only part of the story anyway if you're talking xBase features missing in .NET <g>...
>
>
>+++ Rick ---