Hi kevin,

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

Fair enough.

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

This is not what I mean. In certain circumstances there might be very good reasons to do it this way:

1. There is no back-end data. You've just a dataset that is used internally.
2. You need to have a buffer in which changes reside until the user confirms the changes.
3. For datamunging where creating a new dataset out of one or two others. This dataset might not relate one to one to an existing table on the backend.

Three valid situations where a REPLACE FOR command on local data might be applicable. Now try to do this with ADO.NET and compare the results with the VFP replace command.

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

There is not much what FOX can do and ADO.NET can't, but the difference lies in the efficiency, performance and programming of the solution.

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

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

Well I do have some scenarios in a few of my current projects that do a lot of data munging for different purposes that would be very hard to do without the xBase DML. They're too complex to describe in a few sentences here, so I've got to find an simular example that shows the problem. If there performance difference of 10 times in this cases is real than I'm impressed with .NETs data capability. However I'd expect a difference of at least 20 times or more, not too speak about the complexity of writing the solution.

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

YMMV, but personally I've developed quit a few very complex dataprocessing modules that would be slow in .NET because you cannot use a DML to retrieve and modify your data. I guess that you did not do this in your 5 years of experience and developed applications that do not take the full advantage of FOXs local database engine. I agree that in this case you can write your program in any 4GL language.

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

Again, it depends on what you're doing. If you do not use VFPs datamunging capabilities much and only develop quite straightforward applications, then you should not have much trouble in rewriting the stuff in .NET. However, if you write very complex applications with lots of datamunging (data driven applications) then you're in real trouble with .NET because performance will likely downright suck.

Walter,
>Kev