>Hi kevin,
>
>>>All Mario concludes is that WinForms run "very very bad" - without much in the way of support. Applying his logic, he must not think much of Fox forms either. Rick concludes that Fox will almost always beat .NET in terms of local performance. All I can tell you is that in terms of a simple test that applied Steve Blacks text example at a Fox devcon a few years ago - .NET actually out performed Fox. The gist of Cetin's comments focus on .Net being "bad at data." My response to that is nonsense. The exact same data-class methodology that Rod and I perfected in Fox and VB - equally applies to .NET. ADO .NET Datasets in fact - area huge improvement over stand-alone ADO Recordsets. In fact, ADO .NET is a better client-side engine than ADO.
>
>>The ".Net is bad at data" has been blown out of proportion quite considerably. After requesting data from a source, .Net doesn't handle data, it handles objects which represent the data, .Net is great with objects, hence .Net is great with what we can refer to as data.
>
>Don't underestimate this. I gave you four scenarios of which only one has been worked out.

Hehe, I have worked out a few of them, but I'm also juggling work at the same time, I will have results soon :-)

>This was the easy one. Try to find a .NET alternative to for example the REPLACE FOR command. You'll see that .NET implementation of this command is far and far slower.

In all honesty, I actually prefer just executing UPDATE statements rather than pulling the data over, updating it, then sending it back. So to answer your question, I would simply issue an UPDATE over the connection, I understand that it is not ADO.Net doing the work, but you can do it from .Net, so it is visable.

>.NET is bad at handling data for various reasons. It is for example unlike fox, NOT SCALABLE since all data should reside in memory whereas in fox it can be in temp files (handled totally transparent).
>
>I challenge you to find an example besides passing objects from one object to another where .NET is more flexible at data.

There probably isn't anything more than that from an initial thought, it would probably be better to present something Fox can do with data that you feel .Net can't.

>Also, as I told you before, data should be handled relational not in objects. If you try to find alternatives to xBase commands like REPLACE ALL ... COUNT FOR WHILE ,,, LOCATE FOR WHILE, SEEK, SCAN, CALC FOR WHILE, etc, you're out of luck in .NET. It takes both more programming and CPU resources to accomplish the same. .NET downright sucks when it comes to mung data at the client side.

"Downright sucks" is a bit of a harsh conclusion, I won't dismiss it however, as you know I'm still doing the tests, so once they are through we can conclude it once and for all how we see it.

>Just work out all four scenarious and you'll see the light why the .NET way of handling data is just cumbersome at the least.
>
>
>>However, ADO.Net is (and I have tested to some degree) slower than Fox in processing local "data", it isn't that much slower mind, certainly not enough to sway decisions as to which language to use.
>
>More than twice as slow is considerably slower. However there are scenarious thinkable where the difference can be more than 10 times as much, especially when using complex xbase commands as mentioned above.

More than twice as slow as Fox is pretty damn good IMO, Fox is blazingly fast, even 3 times as slow as Fox would be a bonus. Is the 10x as much an assumption, or can you think of a scenario?

>>The way I view it is that .Net is more scalable due to the fact that classes represent the data, that, IMO is a huge strength, although it's only my opinion and won't apply to everyone - which I guess is why Fox is preferrable to some and .Net is preferrable to others, depends what app you are developing.
>
>This is the greatest mistake they made for .NET. Handling data in objects is just cumbersome as they have scalability problems and relational problems. You cannot use a rich DML to get at your data, modify it or analyze it.

But is it enough to really create a problem? I have used Fox for 5 years, and pretty much nothing else, but I still don't find .Net data-handling that cumbersome, part of that reason is because VFP is OO and I'm quite happy to work with objects.

Again, I still feel it's all opinion, .Net data is slower, we all know that, but is that enough to sway decisions?

Kev