Hi
To be honest, I need to learn some more english to understand well what you said, but I said was somehow intended as a joke, you never give up, from what I've seen here.
Regarding ADO.NET, maybe can be extended to do in a simple way things that we do now in VFP.
It is ok form me to execute dataengine.locate(oDateSet.oTableRef, {parameters}), or dataengine.calculate(...). I think that can be done, in my opinion.
And, for local data engine, Firebird SQL can be used, only 1.4 MB DLL, and has a NET provider.

>Dorin,
>
>There is no one single definition of what a data-engine is. Walter's argument is that ADO .NET does not qualify as a dataengine. Looking at the various defintions - it is clear that ADO .NET fits squarely within those defintions.
>
>All too often, people trot out the argument that anything non-Fox is slow, cumberson, and not flexible as compared to Fox. Too often these arguments are trotted out with little or no basis in fact.
>
>The fact is - it cannot be demonstrated that the combination of ADO .NET + SQL Server cannot be more flexible and faster than Fox + native DBF's.
>
>Keep in mind the burden of proof rests with those who trot out the argument that Fox is definitively faster, more flexible and less cumbersome.
>
>A good book recomendation for many is a book called the Logic of Real Arguments. It is a rather quick read and at $20 - quite affordable. It presents the reader with a series of excercises on how to form solid arguments. Solid arguments are ones in which the conclusions necessarily follow from the premise. For example, if somebody argues that A+B = C - and it turns out that in the absense of B - C still results or if B is present - C may not result - that would be flawed argument.
>
>In this case, Walter argued that in order to qualify as a data engine - it must have its own DML. That argument is flawed on a number of fronts. One - it assumes that ADO .NET does not have its own DML. In fact, ADO .NET does have a DML - as one is exposed through object methods. Also, ADO .NET supports SQL - as I can use it to pass SQL to various backends. The argument is also flawed because there is no absolute definition that requires a data engine to have a DML in the first place.
>
>The additional argument that Fox is necessarily more flexible, faster, less cumbersome is entirely flawed because it states a conclusion with little or no facts that lead to that conclusion. The only fact I see offered is that because Fox has native data and native DML - that must mean that Fox is faster, more flexible, and less cumbersome. If the local data is A and the native DML is B, and the conclusion of more flexibility, faster, and less cumbersome is C - Walter's argument is this: A + B = C. All I can say to that is that I have developed applications without native data (A) - and the applications have been flexible, fast, and not cumbersome. Yes - I have used Fox's native DML to operate on local cursors. But - does that mean that Fox's native DML gives it a presumptive advantage? When it comes to working with local Fox Cursors - absolutely. But, if my local storage mechanism is an ADO Recordset - then the local DML is meaningless. And yes, I have developed apps that relied soley
> on ADO recordsets in Fox - and they were fast, flexible, and not cumbersome.
>
>Conclusion? A + B is not the only combination that equal C. And as a result, Walter's primary arguments are flawed - both in the premise and the conclusion.
>
>Sorry for the long winded response - but you gave some indication of what I would say or how I would get there. I thought I would go ahead and give you some insight on how I approach these things.
>
>< JVP >