Hiya Rick!

>
>>When it comes to high-end apps in an enterprise environment, you are undoubtedly correct. In both cases, VFP or .Net has to broker data with a remote source and the techniques one uses goes a long way towards the success or failure of the project. In both cases, however, it's clear that a data broker is needed at the data server level to ensure timely and efficient delivery of information. If the application is only served raw data and all joins or other SQL functions are performed at the client level, then VFP has an advantage as a data-munging app as .Net, frankly, sucks at that.
>
>When's the last time you've built an app that does that? All processing on the client level? C'mon John.

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.


>
>BTW, when we're talking about this we really need to draw a distinction between client processing and client post processing. Because client processing is quite possible in .NET. You can use a local SQL Server (ok thta's stretching it <g>), you can SqlLight or VistaDB all of which are 'local' processing. The latter two are local file based engines and the latter is freeware and very high performance. ADO.NET is not necessarily Server based. So the real issue is post processing of results returned from queries.

No arguments here.

>
>If you are running a local application that does this then you need to compare VFP with a local SQL Server and in that scenario SQL Server becomes your local data engine. VFP is faster in some situations but not many in that scenario. As far as data munging goes, sure VFP has a wider breadth of value there, but again how much of that do you really use in day to day operations?

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.


>Before I ever looked at .NET I didn't build apps that did extensive data munging client side either. That sort of thing belongs on the server if possible so that it can be reused easily and retrieved in a consistent format by other applications. Just about all of the apps I've built use SQL Server - even smaller internal ones - or even if they used local data for smaller or utility apps they use business objects that do the work. In either of these cases the 'post-processing' hit is minimal with most of the real processing done in the business layer.

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.


>I realize not everybody works this way, but this is a common practice and one that is not exclusive to non-VFP environments.
>
>I just don't buy that you can't munge data in .NET either. The data is there if you want it - either in a DataSet or DataReader and you can manipulate that data fairly easily. True it's not quite as easy as running another SQL command against the result cursor, but it's hardly rocket science to parse through the data and create new result sets which is equivalent of doing record level scans.

Of course you can do complex data in .Net circa 2005 .... just not terribly efficiently.

>>As far as small and medium business apps with no more data needs than a file-server setup or totally local data, VFP beats the crud outta .Net and will probably do so for the forseeable future. It's structurally superior in that environment.
>
>It is true I really wish that .NET had a local data engine or disk spannable version of say a DataSet. This would make some things much easier, but it's not a fatal problem as people seem to make it out here... Disk spanning is less of an issue in .NET 2.0 where DataSet performance is an order of magnitude faster than in 1.1. It's still memory based so millions of records are still a problem, but scenarios that pull that much data should be rethought anyway and even if necessary can be addressed with streamed data rather than in a one shot chunk of 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 guess what I'm saying is that when a database server is required, the query workload must be at that level to make a .Net dumb client work. If there's a mission disconnect between data and client, as is usually the case in the corporate environment unfortunately, .Net falls on it's butt and VFP is - at the least - an equal to the task.
>
>Uhmmm... not true. The problem is that you're equating the data engine in VFP to something that happens to be a component in .NET. You can use a local data engine with .NET, such as VistaDb or SqlLight which are in essense file based local data engines. If you treat ADO.NET the way you use VFP's data engine then the differences start minmizing.

Granted.

>The other thing that is always forgotten is the benefits that you get by using ADO.NET over VFP. How do you ship VFP data around over the Web or between applications? Not easily. DataSets (among other things) make this part trivial and this is actually very important in Web and distributed applications and in many cases also very helpful in desktop applications.

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.

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