>>It's not trivial
>
>Perfect example of how it's often a lot of work to resolve a common situation that one is likely to encounter in any application with .NET. I had a potential client who asked why we used VFP for another client's application re-write mock me a few days ago for advising that client that doing their app in .NET would increase the cost and time-to-completion by anywhere from 50-100%. Admittedly this is just a SWAG, but probably not too far off the mark. Using a framework like MM could significantly reduce that in theory, but we'd have to factor in the risk for that learning curve as well.
>

The problem Steve is, that unless you really force yourself to learn .NET framework, or create your own sub-framework or learn MM.NET, you will never get to that point where you are fast enough in .NET to justify it to a client. I think at some point, you will need to just jump in, and eat some of that learning time, and then you will gain the productivity and benefits of .NET

>Not that I'm being critical - that's just the way things are *right now*, and we can do things *so* much faster in VFP that we owe it to the client to let them know what the tradeoffs are.
>
>This is not the case with an ASP.NET app, though - we're finding ourselves much more productive with ASP.NET than "classic" ASP.
>
Yeah.. eww.. "classic" ASP development, I still think anyone doing a straight web application, w/ no tying into Window components, PHP is by far away the most productive fastest, and flexible scripting language to develop in for the web. Now, ASP.NET is great because you can use the same backend components that your web page uses, your web services or windows application can use them, and you develop one dataaccess layer for everything, and re-use.

Just putting in my two seconds, oh and Steve if you have any questions about Bonnie's example just ask me, she is gone on vacation for a week.

Morgan