Hi dragan,

>I am amazed that nobody replied to this... amazingly, some people really take a week off :).

I guess so... Unfortunately I'm at work all week (Except jan 1st)

>While on one side it can be argued that most of these requests are coming from a pro-Fox side, i.e. that they are just so easy to solve in Fox, I know they're actually coming from life itself. I've had worse - like a customer table where all the 'LLC', 'LTD' and such were in front of the actual name, and the name itself was surrounded by all possible variants of quotes (single, double, twice single, two commas before two singles after, dashes etc) and I needed to make that searchable - using FP1.0. Which was easy, using simple strtran(), stuff(), atc() and substr() with xBase command set.

>So, I wouldn't discard this type of requests from benchmarking the programming/DML tool. Such things happen. I'd rather see the C#ers add what they had succesfully solved using their tool, and to see how it can be done in VFP. IOW, I'd like to see some symmetry, not to discard any of the sides.

Well the start of the thread was an example. Generate an XML document from a dataset. It is amazing to see the kinds of quick solutions you can come up with using the capability of the local data engine to solve this. However it needs a great knowledge of the tool and it capabilities to create such powerful and fast solutions, so you cannot expect the average VFP developer to create such solutions.

Cetin, is one example of such developer who has the skills and creativity to come up with such solutions. He also has some knowledge of .NET so he is capable of comparing the two. I took his idea and created the fastest solution until now in Re: Side by side comparison (strings & local data) Thread #861648 Message #862595

>Now if there was just one more thing: a way to measure the time comparable programmers in both camps spend to solve the problem, and then to measure the time to run the solution. That would be a much more fair comparison.

One thing of course is difficult to measure: The time that is needed to seek an implementation solution, because it depends on the knowledge and creativity of the developer.

Walter,