You might want to start thinking about what I'm saying or suggesting. You might want to pick up the challenges I throw arround with code examples. For example did you evaluate the SET ORIENTED vs RECORD ORIENTED example (see my reply to Fabio) where a SQL statment is compared to a VFP RECORD ORIENTED approach. Evaluate and you might learn something. However, my experience is that no-one is really able to refute it or is too embarred to answer it.

Walter,

You'll notice that I never said anything derogatory about your VFP solution involving seeks (though I'm sure you'll agree that it gets more complicated once you get into nested hierarchies). There's often more than one way to handle the problem -CTEs and recursive queries are another. But the argument loses relevance when an organization chooses a database with all the benefits of SQL Server over VFP as a database.

I'm curious why you would suggest that John (or anyone else) should take your challenge, when you've already shown a proclivity for making up your mind beforehand (oh, wait...I forgot....your "intuitions")

For someone who has accused others of spreading FUD about VFP (I guess we all know how that one turned out), you certainly seem to be attempting it yourself, evidenced by claims that uses of certain SQL functions are inherently "resource intensive".

Walter, I've learned one thing from you - your prejudices involving VFP and .NET go far far deeper than I ever realized. You may find this hard to believe, but in specific private conversations I've had with others, I've actually defended a few of your core beliefs, even if I didn't agree with a number of specifics. (And I've been criticized for doing so). That day has passed. Your statement that VFP is better at implementing design patterns than .NET, because of the way VFP handles data is probably the most insightful comment you've ever made.