John,

>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.

Are using the word "data-engine" on purpose. We are talking about "database engine".

>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.

You've not given any proof or your statments as well. It was you who stated the ADO.NET is a local data engine. I can't find any references that it is.

>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.

You're making up your own conditions again. I never talked about native DBFs. Our discussion was about local database engines. If you want to compare ADO.NET with FOXs native dataengine just compare the speed and flexibility of SQL Server + ADO.NET with SQL Server + VFP dataengine (handling Cursors). If you want to debunk my arguments then please draw proper comparisons.

>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.

Given the implementation of the underlying technology you can only see that VFPs implementation is based on relational data and ADO.NET on an propetary object based solution. I've already given enough explanation that the object based solution is not suitable to handle data relational and therefore is inflexible and cumbersome to work with.

Question: Can you use the results in various ADO.NET resultsets as a basis in a next SQL based query.
Answer: No. This I mean with inflexible. ADO itself does not store the resultset in a way you can process it further in the very same way you aquired the resultset in the first place.

Because of the object implementation it is slow as you have to a fair amount of datamunging though iterating and searching trough collections. Though ADO gives you some methods and properties to make the most common task a bit easier it is really shamefull and therefore 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's just a pitty, you never understood it. In all your thread since your mysterious comeback you've not shown any evidence you did.

>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

Changed your mind, In a previous message you already agreed on my statement?

>Also, ADO .NET supports SQL - as I can use it to pass SQL to various backends.

Nonsense! ADO itself does not support a single bit of SQL on the retrieval side. On the update size I'm not sure what it sends maybe a very simple basic DML, but it is all encapsulted and thus not exposed to the API. For the rest it only supports sending a string to a backend. Whether the string contains an SQL statement or not, ADO does not know. I could send HL7 messages to an HL7 ODBC driver (in such thing should exist). does this mean that ADO does support HL7 ? You cannot use SQL on the resultsets itself. I'm getting real interested in you logic in your reasoning. it is seriously flawed.

>The argument is also flawed because there is no absolute definition that requires a data engine to have a DML in the first place.

Again we are talking about a database engine. There is lot of documentation of the definition of a database engine. a solid DML is a required object within a database engine.

>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.

See above. The reason lies in the fact that it is a non-relational but rather a object based solution. From a number a scientific article (commonly available) we know that the object oriented database did not make it for the mass. 95% of all data is stored relational. Why not object oriented ? Because there are too many problems with it. One of them: There is no uniform DML available while with relational data we've got SQL.

I've already given the outlook example of cumbersome object based data storage. Why could we not use SQL to query and update our emails, tasklists, appointments, etc in outlook. Just because MS did choose for a pure object based data storage (at least from the API point of view). Now we have to iterate through collections and use methods to enter our data into outlook or to get it out. THIS IS WHAT I CALL CUMBERSOME. It could be much easier if outlook had some relational support for it.

Agian the flexibility is that you can use the same DML on queryresults as on the data from which it was derived. VFP as a very rich set of DML

>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.

Flawed? you did not give any scientical facts that support your claims. No examples. You were not able to debunk my statements and you did not prove to know anything about the new features VFP8.

John, you're blowing smoke by telling smooth stories and trying to do simple math on facts. It has been a long time I've seen facts from your side. Nor did I see examples of comparisons between .NET as VFPs way of building application. You constantly make claims you've got experience in this field, but if you read trough all the hundreds of messages you've written there is little prove you do.

If anyone asks me: you're just blowing smoke by making very very fuzzy statements and by comparing apples with orages in a way which suits your best.


Walter,