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

>Consider this - you want to run a series of reports to pdf, html, etc. You want to kick off the jobs and continue on with what you are currently doing. Can you do this in Fox? Yes. But is it as clean or straight forward as simply spawning a new thread? No - not even close.

Hmmm. Not even close ?? In this case I simply would NOT choose firing a thread. Why ?
Because the processing job IMO should not depend on the instance that fired it. IOW, firing a process on the workstation, or even better on an application server is a FAR better choice.

Missusing threads for this purpose is by far NOT a clean solution..

>I think this is where you miss the point. The issue is not whether Fox (or more generically a specific tool) can do a task. Rather, the issue is how efficiently can it be done. The myth perpetuated that Fox requires a few lines of code to many lines in .NET is nothing but a myth. Take two business objects - one in Fox and one in .NET - and I'll bet the lines of code will be roughly the same. As it has been pointed out, there will be scnearios where Fox will require less lines and .NET will require less lines. Where there is the ability on each side to do a task, in the end it all evens out.

I would agree for just programming task which do not have to do with data munging this would be true. However as I expressed there is a lot to be desired when it comes to processing data locally.

>The real issue is where Fox hits the wall - where it is simply not capable of performing a task. There are numerous instances of these scenarios and they are not likely to change.

I yet have to see one that makes a good argument for desktop (database) applications. I simply have not seen any valid argument yet.

>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 important to me when writing advanced desktop applications.

>Why don't you just say that you find the data munging capabilities in .NET just terrible because it is not like Fox.

No that is not the case. It is simply fact that the .NET language is not designed for local data processing on its own. It relies on external data processing means. There is nothing you can within .NET that natively handles large amounts of data other than getting your information by fooling arround with collections of for example ADO.NET. Just doing your data analysis locally is just a real pain.

That is what you are really saying. You and I have debated this before - but in fact - ADO .NET has a local data engine (I can open up local cursors all without being connected to a data store. I can sort, query, etc.... ADO .NET has a local data engine component.)

Query ? on a local ADO.NET cursor ? Don´t make me laugh. You merely can create a filter, set relations and do some basic totalling calculations. That´s all. No support for SQL in your queries. Even a simple task of just increasing the value of a particular column requires you to write a program that iterates through collections. no: REPLACE Column WITH Column + 1. How can you call this a database engine when it is not capable of doing such very basic tasks ?

. This pretty much shows the flaw in your assumption above. This is why I contend what you are really saying is that data munging in .NET is terrible because it is not like Fox - and not because it lacks a local data engine - because it does not.

Datamunging in .NET is terrible because .NET itself does not have any database component that is capable of handling relational data in a set oriented way or even a record based way. In most cases you´ve got to iterated in collections to find what you need and act opun it. Very simple tasks that can be done in VFP with a single or a few lines requires extensive programming to do the same task in a very inefficient manner which is non descriptive and tends to be buggy and takes a magnitude more time than doing it in a SQL or xBase manner.


>I don´t want to manually iterate through collections of ADO.NET to mung my data, nor do I 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....
>
>It is an interesting comment becasue iterating through collections means you are working with objects - something Fox developers claim they like to do. Again, you like and love the VFP cursor (and with good reason I might add).

As I stated before when working with data, you´ve got to leave the OO world and enter the relational world. 95% of all data today is stored relational and for good reasons... It does not makes sense to query the data in a relational way, store it in objects, Mung it in objects, and send it back to the relation backend again. Currently ADO.NET is based on this principle and therefore is inefficient and cumbersome.

Again, there is nothing wrong with OO developed applications, but data should be handled relational. This is the reason why the OO database did not make it into the 21st century. Relational data storage is the way to go for many, many years to come.

>I am not slamming you for it. All I am doing here is drawing out the true nature of your comments. You - like many Fox developers - only evaluate .NET through Fox-Colored glasses. Comparing and evaluating development tools is a difficult job.

I´m looking to what a tool can do for me. I see that .NET has some serious shortcommings when it comes to handling data. That to me is so serious that it justifies what I´m doing with VFP.

>I am not saying you will or should be a .NET lover - I really do not care if and when you ever decide to adopt .NET. If you stay in Fox for the next 6 years or so - that is entirely up to you. There are those here though - that are making serious and important decisions concerning .NET - and this gets to why I write what I write.

I´d not reccomend anyone to follow your advise and draw any conclusion to what you´re saying. If I´d done that a few years ago, I would have several application written in VB6 and found myself in a situation where the platform is dead and have to totally rewrite my applications again for .NET. After that I found that the next version of .NET winforms is not compatible with the current version either and have to do another rewrite. No thanks....

>The bottom line Walter is that those like you - who profess to have evaluated .NET and have concluded that it has nothing to offer - have given .NET short shrift. And - there are those who just might take what you have to say seriously - which would be a shame. That said, if those same people still decided to stick with Fox - I would respect that and consider it a good decision - if and only if their decision was an informed decsion. I will say that if they only get one side of the story - from people like you - and further - and inaccurate side of the story - then their decision is anything but informed.

If you claim to be informative why did I not see you comment on a remark that the current version of .NET winforms is not going to be compatible with the next one ? Why don´t I see you make a true comparison of the two tools other than saying .NEt is better. Where are the PRO´s and CON´s ? Where is your recognition of the value of VFPs´ local data engine?

IOW, I don´t see you publically reconizing even ONE advantage of VFP in respect of VFP. Every tool has it advantages over another. Your act up here is higly doubtable, because you never give the impression of a fair comaprison.

>I know this is likely an excercise in futility on my part because no matter what somebody says about .NET - your knee jerk reaction is to say that you can do that in Fox - or that it can be simulated. At some point, you might just realize that all the work arounds and simulations is nothing more than putting the square peg in the round hole.

Simulating ? When it comes to handling data, .NET is the one which is simulating.

Walter,