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

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

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.

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.

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


Walter,