>Walter,

>Your message below sounds like the VB 6.0 people when it is compared to the full OPP features of VFP. The VB people said, "you don't need inheritence" and "you can implement an interface", etc. OF course, people who have used Fox know the many advantages that implementation inheritance gives you. But, the VB folks didn't 'need' it cause they could simulate it.

IMO, inheritance is far more important than just spawning another thread as oposed to starting another process.

>The fact that you see 'nothing' in .Net redeeming tells me "You don't know Jack" about .Net.

You get the wrong impression. I don´t see much in .NET for desktop applications. For Webbased stuff, I would not reject .NET as a valid platform.

>Take 6 months to work with it, read the articles about it, read the case studies, etc. While the MAJORITY of the great stuff about .Net is Web apps there is alot of stuff there for Win Form apps too.

What does have the winforms have offer me? From what I´ve read. Not much. I´ll lose much flexibility when doing data munging that is for sure. There have been reports that it is slow and won´t be compatible with the next version. Can you tell me why I should spend 6 months in learning a part of .NET that is going to be revised significantly in the next release ?
so what does this say about the current state ?

>>Sure, .NET has advantages too in this area, but of course how often do you need such background processing job ? And if you really need it, would starting a seperate process not be a solution too, though it is not as *CLEAN* as a multi threading option. TO be honest, for the average and even advanced VFP application developer I don´t see much value in this argument.

>Cause you don't have it in VFP, you don't think you need it. You don't know what you don't know. Yes, I guess cause of the Windows OS you could spawn another process with VFP, but you have no control over it, no call backs, no access to the events, etc. If you choose to monitor that process with VFP, you've hung up your only thread and really didn't gain anything.

Ehhh, what about a out of process server component? There are certainly valid ways of handling those things. I agree with thread you can do more things and some thing even better, but I don´t see any examples that raise my hair to let me say... Yes I need that and I need it now... IOW I can´t see major circumstances where I need that right now. Examples please..

>>All of course is about which platform is most suitable for developing desktop applications. There are many criteria involved to make a proper comparison and not all arguments have the same weight.

>True, but some of your 'arguments' are just plan wrong or missinformed.

Which arguments ?

>>As I expressed before, I find the data munging capabilities of .NET just terrible because of the absense of a local dataengine, which is esspecially

>If you keep banging that drum, it will break. There is a local data engine in .Net... ADO.Net, which is based on ADO which has some VFP cursor roots too.

ADO.NET by definition is not a local database engine but rather an outgrown data storage mechnism. How would you solve something very basic like:

REPLACE ALL Column1 WITH Column1 + Column2 + 1 FOR Column3 = cSomevalue

In ADO.NET ???

Also, No concept of indexes, No SQL (Other than passing it to a SQL server)
If a database engine is not capable of solving such simple things it by definition is NOT a database engine. ADO.NET is a laugh when using it as local database. It is a layer on top off ODBC or OLE DB and SQL server, not much more.

>>important to me when writing advanced desktop applications. I don´t want to manually iterate through collections of ADO.NET to mung my data, nor do I

>Man, I wouldn't either. That is what T-SQL is for.

So how would such mechanism qualify as a LOCAL database engine ? This is a remote solution.

>Or, if you are using VFP data a stored procedure. Even in the VFP apps I write most of the large batch data processing is done with stored procedures. Could I do it in VFP, sure, but it is less efficient moving all that data over the wire.

While it could be far more efficient to use the available processor resources to let each application process it locally in stead of loading the SQL server with stuff that should be done locally. BTW, I don´t think T-SQL is particular suited for doing data munging. The programming options are too limited. However this will likely change with the next release of SQL server since it supports .NET integration.

But this was not the discussion. It was about the local database engine. SQL Server does not fit this scenario.

>>want to use an external source for it (SQL server) for network load abnd performance reasons. In what respect: what does .NET have to offer me. Virtually nothing....

>Um, using SQL Server will REDUCE your network load and INCREASE performance, if you do it properly.

Oh man.... What do you think what will happen when you upload your local datasets to SQL server, process there and return the results again? Compare that with a VFP local database solution where there is no network trafic at all because all is handled on the client. Just saying that SQL reduces network trafic is another marketing statement taken over by so many people as fact. You´ve got to see in what circumstances.

>Sure, but they had to build it in VFP code. In .Net, you get it inheriently. OH, and don't tell me that's not better in this case when you main argument is the data handeling in VFP is better cause it is inherient! You can't have it both ways.

Sorry to say so, but what is the relevance for such minor item. I don´t see the relevance if it only takes 5 minutes to deal with this in VFP as where it is automatic in .NET. Those 5 minutes are IMO not an argument in favour for .NET. It is insignificant....

>>My class libraries are built in the executable, so no problem here also. For application dependant resources, you can store them in the working directory to prevent versioning problems.

>So, your users need to update a full EXE to update your app. Which means shutting down the app. Where in .Net, if you seperate your command libs in one DLL and your business domain in another, you can just update that one DLL.

How would you update an application in .NET while it is in use? Normally I just place my new exe on the server and each new launch will use the new EXE. For more significant updates that requires conversions or table structure changes everyone needs to be out of the application to do the conversion. I don´t see that beeing much different in .NET . Personally I don´t see any objection in replacing a whole new EXE of a few megabytes. What is the big deal here ?

>>Other than a universal VFP workstation setup you don´t need to do this for a VFP application as well. I don´t know about .NET, but of course, VFP versions do not conflict eachother....

>No, you can't. Lets say you have two VFP apps... One is VFP 7.0 and one is VFP 7.0 SP1. The machine runs both, which version of the runtime is on the machine? Point is, you CAN'T do this, unless you put the correct runtime for each app in that apps folder, which is a maitenance nightmare. With .Net you can have the 1.0 framwork and the 1.1 framework, with apps that runn against each, side by side with no conflicts. You just CAN'T do that with VFP. (Unless you are talking about major versions.)

I was talking about major versions. I don´t see much relevance for minor versions though. Why would I want to run one application on VFP 7 and the other on VFP 7.0 sp1 ?

>Well, I didn't make the '3 lines of code in VFP is alot is .Net' comment. Doesn't that also have to be 'qualified'. But, whoever said it (don't remember who) didn't qualify it at all.

And I´m willing to qualify this for the case of datamunging

Walter,