You are right, I've got plenty of work to do..
Back to work.

Walter,

>Walter!
>Don't you have work to do?
>I understand that some people have all the time in the world to spend here day and night preaching whatever they want ( IMO they don't work in VFP ), but i know you should better go and keep on making money with VFP, and just let these futile threads die.
>
>Respectfully,
>Jaime
>
>>John,
>>
>>
>>>>Microsoft does not have plans to merge Visual FoxPro into Visual Studio and .NET, but instead we are working on adding many of the great features found in Visual FoxPro into upcoming versions of Visual Studio, just like we've added great VS features into VFP.
>>>>
>>>>YAG:
>>>>http://blogs.msdn.com/vsdata/archive/2004/06/16/156978.aspx
>>
>>>>See above, The ones I could find quickly.
>>
>>>That is fine...except that does not mean .NET is inferior to VFP.
>>
>>It is very difficult to say that one language is inferiour to another. VFP has its strengths and .NET has its strengths. It depends on what features are important to your applications. If it demands a high integration of internet interop, then .NET seems to have the better cards. If you're into win32 RAD development and highperformance data usage is an issue, then VFP has the better cards.
>>
>>The messages of both YAG and KenL do indicate that .NET has a lot to learn from VFPs data features. I can't conclude any other then that .NETs data handling is inferiour to VFPs.
>>
>>>And...when you read the statement more carefully, it is fairly ambiguous. i.e., you don't know which features will make it in - or to what degree they will make it in - or when they will make it in.
>>
>>That is irrelevant. The fact that they're looking to implement VFP data handling features should say enough: The VS.NET is looking to improve its data handling. Whether or not exact features found in VFP are going to be implemented and in what form does not matter as long as they improve the product in such way that it can more efficiently handle common data handling problems. It really does not matter how a REPLACE ALL field1 WITH cValue FOR cSomeCondition IN cAlias is going to be implemented, as long as it is quick and ease of use is comparable.
>>
>>The message states that .NET can learn a lot from VFP. When reading Kens statement you can see its data. Conclusion is that VFP still has a significant advantage in this area, (Which has BTW been confirmed by a lot of .NET developers and VFP developers doing .NET). You're in denial regarding this fact.
>>
>>
>>>Again, you are hanging your hat on a non-existent hat rack here Walter.
>>
>>Nope I'm not. You're the one in denial, not me.
>>
>>>>>No doubt, there are some benefits - in the abatract - as to how VFP works with data. That said, from a PERFORMANCE standpoint - VFP has no material advantage over .NET.
>>>>
>>>>Huh, can you prove that?
>>>
>>>Already have...and I believe there are stats on the UT.
>>
>>Care to draw a link. I asked for prove? In the cases I've seen VFP wins hands down in a performance test in handling local data, esspecially when dealing with larger resultsets.
>>
>>>>I've thrown a dozen examples of how VFP is superiour and you nor anybody else reacted, and now you're asking me for prove ?
>>
>>>That is only your opinion. Running tests that you can run yourself takes it beyond opinion.
>>
>>Huh, since when did you provide running tests ? You've been strategically been avoiding data handling performance. So you'd better put your money where your mouth is, and show me those tests, if they exist at all.
>>
>>>Case and point...in your opinion, RV's are superior. From an objective/technical standpoint, although you are entitled to your opinion, it can at best be classifed, as uninformed and unsupported as a best - or even marginally suggested practice.
>>
>>You're changing the subject here. This discussion is not about RV's vs SPT vs DBFs or whatever. It is about handling local data. Please stay on the subject.
>>
>>>There is ton's of prove it is far easier to create high performance data processing routines in VFP than in .NET.
>>
>>>Really...where would that be? I understand it that from a VFP perspective - which is very biased - this may appear to be true. Looking at it objectively however, it is anything but true.
>>
>>Objective ? Since when are you objective? The fact is that most out of the VFP world is not familiar with the ease of data processing. We all know the VFP is MS's best kept secret. When you were a VB developer and have been trough various data access techniques like RDO, RDO2 and ADO, then ADO.NET surely is an improvement. However when you're comming from the VFP side it is a significant step back in various data related aspects.
>>
>>>And..asuming we are talking about raw data-munging, even if the point were conceded, in the grand scheme of things that the world views as important - raw data munging is not one of them.
>>
>>Ahhh, so you'd agree that VFP has an advantage in raw data munging? Whether it is important to grand scheme is yet to be determined. How many projects have failed because performance was bad? How many programs could have been far better and faster developped with more data processing features against a lower price? IMO, it is not the achievement of VFP in the area that makes VFP a great tool, but the total lack of understanding what it takes to build enteprise systems efficiently at the software development vendors.
>>
>>You would be suprised how much trouble managers at large companies have to replace their old dbase, clipper, Fox2x and VFP application and replace them with VB/SQL or .NET/SQL solutions.
>>
>>Yesterday I was at a meeting with KenL and YAG and met some other dutch people working at large companies like AKZO and KLM. In both cases the management launched investigations to replace those systems but came to the conclusion that given the complexity of those systems it was very difficult to replace them. In VFP you could easily write a few DML commands that creates a total nightmare for a VB/.NET programmer.
>>
>>Sure, you can play your favourate game and say they're biased because they work with VFP. Maybe true to some extent, but more important THEY NOW how it can be done more efficiently by using VFP.
>>
>>>Put another way, if 10% of the functionality invovlves data munging, all you have really said is that 10% of the app should stay in Fox - but the other 90% can go to .NET or something else...
>>
>>I can't follow your logic. You can't draw percentages. If only 1% of the functionality is involving data munging, but this a critical part of the system, the rest is irrelevant: The application does not work without it.
>>
>>Moreover why would you port your application to .NET is it does not have any advantage to you, besides better marketing. Sure about 90% - 95% of what we do in VFP can be done as efficient in other languages as well. This has been always the case, whether it is VB, Deplhi, C++ or .NET. But if you relalize that a simple command like:
>>
>>

REPLACE ALL Field1 WITH Somevalue, Field2 WITH SomeOtherValue FOR Field = SomeExpr IN MyALias

>>
>>takes at least 4 other commands in .NET and a
>>
>>

SELECT a.Somefield ..., b.Somefields ... FORM Alias1 INNER JOIN Alias2 ;
>>    WHERE EXIST (SELECT * FROM Alias3 C WHERE C.Value = A.SomeField)

>>
>>takes many, many more than that, then you simply know that this is VFPs strength. And no, I'm not talking about DBFs, but just plain local cursors.
>>
>>>Again, you are hanging your hat on a marginally important point...
>>
>>That is YOUR opinion, not a statement of fact. I've seen too many cases from reality that really showed it does matter. You ever wondered why about 60% of all IT projects fail ?? In many cases because performance was poor or it took to long to program the logic to handle data.
>>
>>>>If you'll excuse me, I've got to attend a session with Ken Levy and YAG within a few hours..
>>>You along with everyone else who paid the attendence fee....
>>
>>It was free. No attendance fee at all.
>>
>>John, You just proved my point I was trying to make all along. Despite your effort to say that VFPs data managing performance advantages is a myth, you just admitted this is this thread. My thanks.
>>
>>
>>Walter,