>1) utilise a true local database engine,
>2) one that sported DDL/DML,
>3) one that could be indexed locally,
>4) one where the system could use macro substution,
>5) and on the fly code execution,
>6) and in-line SQL,
>7) and in-memory cursors would auto-span to disk when required
>
>
>First, a client isn't very unlikely to ask for these characteristics.

Don't you mean likely? I think a client is more likely to value the ability of an application that powerfully handles data and metadata, client-side, than an application that can multi-thread and raise and respond to events. Really and truly handling data, client-side, is far easier to understand, appreciate and grasp by your average client than the internal "advantages" you espouse.

>They are, however, more likely to ask for the ability to run on a mobile device

That all depends whether they want an application that runs on a mobile device. I am currently involved in a £2,000,000 C#/.Net/SQL server development and there is no requirement anywhere for the application to run on a mobile device.

>and for the application to continue executing subsequent lines of code without waiting for function calls to complete.

I don't think I have ever worked with or for a client who has specified multithreaded execution over a lightning fast, native local database with flexible dynamic code execution. To the typical client, this kind of detail is "Double-Dutch".

This is where you're becoming somewhat esoteric about the typical clients' requirement(s). Of course you are going to say that you deal with this type of client all day every day. Most consumers of computer systems want systems that are fast, reliable, scalable and simply do the job. They are not too fussed what design patterns, coding techniques and internal architectures are employed by the developer of the application, as long as the application meets with the requirements of the specification, is delivered timely and on budget.

Kevin, you are clearly dreaming up the the type of client expectation(s) that you have specified (and that I have subsequently highlighted above). I repeat, you are simply hiding behind the internal specifics of your chosen platform in order to duck Jeff's original challenge. It is likewise clear that you are, as evidenced by the nature of your response, frankly speaking, wriggling.

>But regardless, several of the things you described can be done under the terms of what I've agreed to (VS.NET 2005 and SQL Server)

Keep telling yourself this Kevin; however, it will not make it true. I am currently using VS.NET 2005 and SQL Server 2000/2005 and no matter what you say, it doesn't do the kind of things I referred to in anything like the same way (or at all) that a VFP/SQL server combination can. Unfortunately for you, on this occasion, you cannot hide behind the "how much .Net experience do you have?" mantra that you so readily preach, in order for me to be qualified to make these conclusions.

Your stance smacks of an agenda. It certainly smells like FUD to me.