Kevin,

It would help if you drew some examples here. Of course you can mimic a SQL Statement like:

SELECT ....., SomeField FROM MyCursor ;
    UNION 
    SELECT DITINCT ....., "XXXXXXX" as SomeField FROM MyCursor WHERE ... SomeCondition ;
    INTO CURSOR MyCursor

And

SELECT ...... ;
    FROM MyCursor ;
        INNER JOIN MyCursor2 ON .... ;
        LEFT JOIN MyCursor3  ON .... ;
    WHERE NOT EXIST(SELECT .... FROM MyCursor2 WHERE....)
    INTO CURSOR MyCursor4

or any other SQL statment by just building a solution to achieve this.

However:

1. You´ve got to build a seperate procedure for each and every SQL statement.
2. As the application goes more data driven you have to write more of SQL mimicing procedures
3. It very much harder to build and debug the procedure than doing the same with a single SQL Statement
4. As you read through your code, it is way less readable because you have to open and read a procedure for each and every SQL mimic (maitainability).
5. Performance in many aspects is going to be an order of magnitude less than VFP.


>But this idea that data munging is a nightmare in ADO.NET is often put forward by those who haven't taken the time to fully research/investigate what ADO.NET can do.

I did. I went through the whole documentation of ADO.NET, read many, many articles regarding this.

>You're talking to a guy who personally spent weeks of his own time re-writing a Foxpro invoicing/job costing app in .NET, to validate that data munging CAN be done.

Can you write a database application in assembly? Yes you can, but it does not mean that is not a nightmare when things get complex..

>"A clear no-no for data driven designs."

I think you don´t understand what data driven means. Most database applications are not data driven. Your application probably is not. Data driven means that instead of all programming code is running the application, database information drives the application.

Examples:

- Buisiness rules stored in a table (and offloaded into a VFP cursor) in stead of hardcoded
- Your menu structure stored in a table instead of using the menu designer
- Letting the users defining their own queries, based on meta data of regarding the database stored in the executable and storing this info into a table.
- Letting the users defining their own validation rules.
- Letting the client themselves add more modules to you application
- Letting the client customize the look and feel of your application
- Specify advanced rule and role based security.

Not something that would apply to the average VFP application. But this is where we are heading for in enterprise computing (ERP/CRM). .NET simply does not have the muscles yet to handle this type of applications. No matter how you´d put it, you need an advance database engine at your client. I´m sure, that with LongHorn, .NET will go this way (Because the Longhorn OS is going to use database technology extensively), but it is not there yet.

Walter,