Bob,

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

Yes...

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

See for example the post of mario montoya. He is not using VFP as a primary tool but outlines the problems with winforms, so he would not be VFP biased.

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

This statement was in a reaction on your comments on using a seperate process. With a out of server process you do have reasonable communication between the processes and allow you to do background processing.

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

How is this going to speed up my application on a single processor PC ? They share the same CPU and therefore you would not gain much. Only in the situation where you want to use background processing (asynchronous option with remote data) it holds water. However these situations are not ideal for a number of reasons. I know that other programming environments use this strategy because of slow UI elements showing the data (filling collections in Listviews, Flexgrids and Treeviews). Since with the native controls like grids and lists you don´t have such a serious performance problem though.

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

You don´t have to explain what multithreading means. I´m perfectly aware of the differences between processes and threads. However I don´t see much applications in a desktop application for that. Using (out of process severs) processes might be a perfect alternative and in some situations make more sense than using threads because of the nature of the task.

For example background printing. Is there any good reason to do this in a seperate thread ? When I close the application, the thread closes also whether it is finished or not. A seperate process will stay alive until it is finished.

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

Unless you use processes in stead of threads. Or use a IIS solution to make a multithreaded VFP solution. BTW, there is one article available that shows how to build multithreaded VFP applications. I did not save the reference, but it is possible. Of course not as straightforward as you would do in a language that natively supports multithreading, but still.

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

How does an item on the wishlist tell you the relevance of it. I also see items on the wishlist like native compilation. So what does this tell ?

>Like, you can't munge data.

I never said you can´t mung data, but rather that the data munging capabilities are terrible because it requires either a database backend, or iterating through collections. Both ways are bar far not optimal.

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

Like ODBC. Could we call ODBC a database engine. No. It is just a piece of middleware.

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

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

YOu don´t get it. ADO.NET itself does not have any means of processing this command. It relies on a remote backend to process this. Again THIS IS NOT A LOCAL DATABASE SOLUTION. It is far slower and burdens the network compared to a local database engine solution.

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

ADO.NET is a data store in the way that it can store data. It has some very basic methods of filtering, sorting and summarizing data. But that is about all.

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

Then you´re using a third party which is exactly my objection. There is no tight intergration of a local database engine with the native language which is at the least troublesome.

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

Data should be handled Relational, not OOP. OOP is too troublesome in munging data. There is enough proof of this in the DB world. Look at the current status of OOP databases.

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

There is not much want you can´t do in any specific language as opposed to another. However datamunging is FAR easier in VFP than in a .NET environment: My good old example

Get as fast as possible the upper boss of any employee.
VFP:

LPARAMETER nPersnr

DO WHILE KEYMATCH(nPersnr,1,"Employees") AND SEEK(nPersnr,"Employees",1)
ENDDO

RETURN Employees.persnr

However this is not the point. .NET does not have a local database engine, so it is not integrated into the language which is very troublesome when building desktop database systems. Using SQL server is expensive, MSDE has scalability issues and is more difficult to install and maintain. So I could rely on a VFP database, but why the hell should I do that when it is much more easier to this in VFP anyways.

.NET itself does not have any integrated DML. The gap between the language and the data is far bigger than in VFP where the whole languange is optimized arround data from a database.

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

So, What is agains getting the data you want from the server and post process it on the clients? This is very common for data intensive database applications (Data driven designs). In a hell lot of situations it does not make sense to process all data on the server. Why burden the server with post processing data that can be done more efficiently on the client anyways and free (CPU, memory) resource form the server ?

An example. My application has a fairly complex authorisation model. However the data containing the rules are relatively small. When the application needs to show data to the GUI, it needs to be validated if the data is not visible, readonly or readwrite to the user on a record by record basis? How are you going to implement that when processing all data on the server ? because of the complex autorisation structure processing it on the server is not an option. So the client has to do a bit of datamunging to validate the userrights for each and every record. This is faster than in a local database engine like VFP than relying on any external source.

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

No in its current state it certainly is not. Look at the articles about the next release of SQL server (YUKON ?) and you will get another impression. Data munging in SQL server with T-SQL has a lot to be desired when it comes to efficiency. Besides this. SQL server better serves the raw data, and let it analyze on the client. This is far more efficient...

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

Of course simple applications can run on any environment. When it becomes more complex like in data driven applications then it becomes a different matter. I´ve got a dozen applications that would do fine in a .NET solution. However some very data intensive application would have serious problems performance wise.

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

I think the essense it that in .NET the data is too seperated from the .NET language. There is no tight integration.

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

So what does this then have to do with the discussion of ADO.NET beeing a local database? So how does this fit a scenario where you want to post process your data available in a ADO.NET object ?

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

VIRTUALLY no advantages. The advantages I´ve seen here are IMO about not relevant to desktop database systems.

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

The UPDATE statement is not a .NET integrated solution. When it comes to munging data VFP is far superiour to any .NET solution without relying on third party solutions. See about about the upper boss example. It is all about performance VFP simply is faster when post processing data.

Walter,