>Hi Rick,
>
>We are following this interesting thread. Our shop created a VFP framework that we use for all our apps and with good success. When researching what it would mean to create a similar framework with .NET one question we have is what it would mean for smaller apps that we distribute as standard apps on a CD that should install automatically. Can you still do that with .NET and an MS-SQL back-end or is installation then much more complicated than we do now?

Sure you can still do that. Although small depends on whether the .NET framework is installed on the client or not - and if it's not you need to distribute and install the .NET runtime which is about 23 megs of extra files (however, your application EXE files tend to be rather small).

You can think of the .NET runtime in the same ways as you do of the FoxPro runtime - it adds significantly to your setup. To some degree this is mitigated by the fact that the .NET runtime is getting pretty widely distributed (SP2 of XP includes .NET 1.1 for example and we can only assume that the SP will include .NET 2.0). This means you need to check or allow users to choose whether they actually need to install .NET.

+++ Rick ---

>Regards,
>
>koos.
>
>
>>Hi John,
>>
>>>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.
>>
>>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.
>>
>>
>>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?
>>
>>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 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.
>>
>>>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 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.
>>
>>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.
>>
>>>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...
>>
>>+++ Rick ---
>>
>>
>>
>>>
>>>>>Well, the fact that I never needed to handle a million records does not mean it might not be an issue for others, I have a program that generates 2D graph that needs near 75K records, and it is simple, so I can certainly see that more complex or 3D graphs requiring a million records. But, even if you can stream the data a record at a time, why would you do it if you can pull the data faster at once to process it locally to generate your graph/object or whatever visual representation you need?
>>>>
>>>>Streaming does not imply pulling data slowly or reconnecting. In .NET using a DataReader streams the data while connected and you access the data while it's coming down one record at a time. Add to that the ability to do this on a background thread while other UI or process work takes place and you have the ability to very efficiently pull data down to the client. Streaming data in this fashion is very low level and likely going to be faster than streaming data into cursor for example - certainly than synchronously waiting for a query to complete.
>>>>
>>>>Look, my point is not that .NET is necessarily better at doing this - it's just different. Like I said a bunch of times before here - if you think of doing things the VFP way in .NET you'll think it sucks. But with the right approach and some different concept you can - most of the time - provide the same functionality with the same or better performance. People are writing high end applications in .NET every day and people write high end applications in VFP. It can be done in either and if you know how to use the tools either allows you to do it with reasonable ease.