HI kevin,

>Yes, I had to write some code...that was part of the process of learning C# and .NET. About a year ago I spent part of a week writing a toolkit for data access...I've been a Fox guy since 1988, and wanted to put together a 'library' to do similar data munging in ADO.NET...it was time well spent. I do recall that part of our daily work routine is writing a few lines of code here and there. <g>

>Since then, I've had to do some fairly extensive data work in ADO.NET, and really have yet to find myself 'missing' anything that was in VFP.

>You say that the approach I posted is 'less efficient' and 'slower'...have you benchmarked them yourself in .NET? Would you care to share the results?

I did not benchmark those myself as others did. If you do a search on the UT, you´ll find some examples. I´ve put 4 challenges on the UT of doing this in .NET in my message to Kevin Lawrence. The comparison that have been shown here up to now have shown that VFP is at least twice as fast in simple data handling operations. I´m trying to extend that into more complex examples.

The fact is that for finding alternatives for the xBase commands I listed earlier you´ve got to do a fair bit of programming, so the solution consists out of more programming lines, is more suspectible to bugs as a direct result to that and is therefore likely to be slower as each programmming line has to be interpretated. In VFP an xBase command is intepretated once and after that the internal c++ or assembly code takes over and executes the task very efficiently for multiple record (as is the case for methods in ADO.NET).

Therefore self made DML commands may be a solution in accomplishing a goal, but in general its performance is far inferiour to a VFP equivalent.

>I'll be happy to share mine...I created an unindexed 50,000 row data table, and was able to do random locates in a second or less. Keep in mind that much of ADO and ADO.NET came from cursor technology.
>
>If the situation were reversed...if .NET had some key feature that many felt did not exist in VFP, and someone demonstrated that it could be done in VFP through a custom function with similar outcome...the VFP developer would likely state (and rightly so) that while it took 10 lines of code, it works similarly and won't need to be modified for quite some time. So why is this any different?

It is about the performance and relevance of that function.

Walter,