>>there are other ways to solve big data crunching problems as any SQL Admin will tell you. Doing processing on the server instead of relying extensively on client side processing is one thing.

I think most people here are aware of the fact that SP makes really good sense with "modern" tools. What I see is that some people are turning necessity into virtue. Local processing is too difficult with their chosen tool, which confirms that central processing is always better. Which is why VFP's local processing advantage is irrelevant. I see the same thing when mySQL people say that Stored Procedures aren't that relevant... an easy argument when one has decided that mySQL is "the best" and does not offer Stored Procedures. ;-)

>>Not using DataSets to pull large amounts of data back for display or manipulation is another as DataSets do horribly with large amounts of data because they are essentially memory based structures (collections).

Exactly. If it were always possible to avoid large local datasets, I'd agree with you. But when it comes to heavy processing involving huge static lookups, the automatic disk spanning ability of a lousy VFP table or cursor can save the customer $100,000 worth of server. Those lookups perform almost instantly, right there on the target machine without any network access or impingement on anybody else. Sure it could be done with a SP. But get a whole gaggle doing it, and just like Billy-Bob said over on the wiki- "SQL Server performs better than VFP because if it doesn't, you can buy a bigger server". ;-)