>>The 64 large question - what is the objection to my three terms?

Firstly, there are actually 4 terms. Here is the most important:

>>This is straight VS.NET 2005 Enterprise Architect versus VFP9, with a SQL Server 2005 back-end , straight “out of the box”.

So you're seeking to pit the premier $2499 version of VS.NET against standard VFP. If "Fairness" were the goal, you would have selected standard Visual C#.NET for yourself. And not allowed to use any of your classes. Either that or you would allow the VFP developer to include a CASE tool, a web development tool and other productivity tools to match those you are awarding yourself in the premier version you chose.

Moving onto the 3 other terms you sought:

> - Application must be able to run on a mobile device and run in a browser (more marketable)
> - Application must support asynchronous processing
> - Application must be able to raise and respond to events

VFP can serve HTML, but it is a chore without addons. VFP does not run at all on a mobile device except by serving HTML, or by interfacing to add-ons. Which you have sought to block. You do not need me to tell you this.

Asynchronous processing- with add-ons in VFP, no problem, as long as the developer judges that it is necessary. But you've blocked use of add-ons, and asynchronous processing is not always necessary. in fact, quite a few of the reasons you'd want to use it are better done using persistent autospanning local datasets and local munging in a VFP client or tier. Which is something I'd expect to see highlighted in any contest.

Raise and respond to events- I can see why you might want that as a dotNETtie, but a VFP developer is far less likely to want it for a data app. Which creates another arbitrary hurdle for the VFP contestant. What sort of need are you predicting here?

Summary: it seems that you've created these 3 hurdles to impose a dotNET flavor on what was previously a neutral proposition. Unless you have some other explanation?