Everybody wants to add their own $.02, so here's mine.

I REALLY like the idea of tighter integration with SQL Server. VFP cursors have many performance and flexibility advantages over ADO recordsets which already gives VFP an advantage over VB/VC. That's not to say I don't use ADO, it's great having both! OLEDB support is a must, if not from a technical standpoint, from a marketing one. ODBC sounds old, even if it works well. Having to set ODBC connections up outside of the app and out of the app's control has always been a pain. Built in connection management tools would be great.

Secondly, an overhauled report writer would put the idea over the top for me. I wouldn't want to mess with the existing MODIFY REPORT/REPORT FORM, it's complex and needs to maintain backward compatability, but adding new MODIFY OUTPUT/OUTPUT commands that are object oriented and can output as HTML, self-viewing .EXE, e-mail, preview, to BMP, to TIF, to JPG, to printer, etc...

Finally, even though VFP isn't in the CRL, it needs better integration with web services. Currently, publishing web services from VFP DLLs means installing the SOAP toolkit (not even on the VFP CD) and finding and running the wizard. Accessing web services from a VFP form doesn't seem to work at all. It seems the current approach is to use a custom class dropped onto a form which indicates support is not built in.

Thanks for you ears!
Mike