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

That's fine, you can have that opinion. But, did you really look?

>There have been reports that it is slow and won´t be compatible with the next version.

Please provide your source for this. I haven't seen or read that.

>Ehhh, what about a out of process server component?

How does calling an out-of-process component allow you to spawn and control threads from your single threaded VFP code?

>Examples please..

As you said, this is situation specific but, how about loading your form on one thread and getting the data on another thread?

How about backgroud printing, or communications? Every use Free Agent? Know why you can read messages in one news group while it is getting messages in another news group... Yep, cause it is threading the communications to a backgroup task.

Quicken does alot of this too... so does IE.

Of course, I can't point to a VFP app that does it, cause you can't DO IT in VFP.

Is this only ONE feature of .Net, yes, is it MINOR, well that depends on what your apps requiertments are... but, I have also seen multi-threading on the VFP wish list for MANY years now.

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

Like, you can't munge data.

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

Ok, ADO.Net is the API you use to manipulate your data store. You use the same API weather you are using XML files, DBF tables, MBD database or SQL Server database.

>REPLACE ALL Column1 WITH Column1 + Column2 + 1 FOR Column3 = cSomevalue
>In ADO.NET ???

UPDATE MyTable
SET Column1 = Column1 + Column2 + 1
WHERE Column3 = cSomevalue

Pretty similar eh?

>Also, No concept of indexes

As you said, ADO.Net is your data access API, not a data store, so there are no indexes, that would depend on the data store you are dealing with.

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

As you say, ADO.Net is NOT a database, it is a data access api. You can use VFP database in .Net as easily as you can use SQL Server... and you still have all the speed and features of the VFP data engine at your disposal.

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

ADO.Net is a data access api. It provides me a objectified access to the data I wish to retieve. I can do anything with that data I want using standard OOP commands. I can also get subsets, define views of it, etc, etc.

No, it is not an 'inherient' data engine, but you haven't mentioned something that you can do with data in VFP, that can't be done in .Net.

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

That's silly. You still have to move the data to the client.

Now, if you WANT to do it that way in .Net, you are more than welcome to. I haven't seen the advantage to that yet. SQL Server is designed to 'mung data' even though you seem to think it's not.

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

Well, I have a Payroll/HR application. Every bath process is done as Sprocs in T-SQL. These batchs are re-wrties of our 2.6a FoxPro xbase row by row code. SQL Server runs the payroll just as well as the 2.6 xBase version, and the SQL Server version is faster given similar speed machines and networks. Oh, and the 'remote nodes' process the payroll just as fast as the local nodes, cause in both cases it runs on the server.

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

True, you can have sprocs and send SELECT statements to VFP's OLE-DB provider just as well as SQL Server, using the same ADO.Net commands you would use for SQL Server. I do agree that it would be nice to have a VFP managed data provider for ADO.Net so you don't have the extra OLE-DB layer to go through.

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

Why would I do that? If the data is on SQL Server, I don't have to 'send' it there.

Of course, if you are talking about DBF only, then I would still create either an SP or create SQL that will accomplish the munging, and get the 'results' that I need in the client, rather than moving all the data to the client (from the file server), then processing it, locally. Of course, once again, it is possible.

>Sorry to say so, but what is the relevance for such minor item. I don´t see

It is just one of many. You say .Net gives you NOTHING... I would disagree. You just feel what it does give you doesn't sway you. Fine with me... It won't hurt me or my feelings if you never write a .Net app.

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

Sometimes stuff happens that you don't want to happen.

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

OK, so, tell me what you can do with a data store in .DBF with a VFP desktop application that I can't do in .Net? I still haven't seen any particulars except your above example with a replace statement that is as eaisly done with an UPDATE statement.

Once again, I like VFP alot, and have worked with it for many years. But, what I have done in .Net so far, it is not a lack of data access/processing ability that has held me back.

BOb