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

Data engine, database engine - same thing....


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

Walter, I don't have to offer any proof. Lets review...it was YOU who said that ADO .NET is does NOT have a data engine component. That is YOUR assertion. The burden of proof is on YOU. In response, several defintions of what a database engine is was offered and I articulated an opinion that states in effect - ADO .NET fits squarely within those definitions.

At some point, you need to learn that when YOU make the argument, the burden of proof rests with YOU.


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

Again, you are the one making the comparision. YOU are the one saying that he combination of VFP DML + VFP's Data Engine is better, faster, more flexible, and less cumbersome that ADO .NET + SQL Server. When I say local data, I do mean data manifested as a local cursor in Fox. DBF's are just a storage mechanism.

With respect to "debunking" your argument, that pre-supposes that an argument has actually been made. I'll concede the point that you have made a number of conclusions - but that is about it.


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

Lets de-construct this. In effect, you say VFP is relational and ADO .NET is not - that it is an object-based solution.

Right off the bat, your logical flaw is that objects and relational models cannot co-exist. Isn't this precicely what the the DataSet is? A dataset is a collection of tables that can be related?? How is that not relational?

I could stop, but lets go on. You then go on to conclude that an object based solutiions is not suitable to handle relational data and is therefore inflexible and cumbersome to work with?

Even if you could make this conclusion, please tell me where in your stated premise allows one to draw that conclusion. The fact is - ADO .NET is perfectly capable of handling relational data. I am non-plussed as to how you could possibly make this argument.


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

Wait a second... I can absolutely use data in an ado result set as the basis of another SQL-based query. As for post-processing the data, I can fabricate data tables, I can filter and sort data, etc.

In this instance, your conclusions are entirely 100% wrong.


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

Just like the preceeding argument, your flaw is in taking your specific opinion and making it a general rule. The fact is, objects by an large - are easier to work with. Iterating through collections makes for cleaner code.

In effect, what you do here is start with the premise that object-based implemenations are slow - and therefore are cumbersome. You start it at the beginning: "Because of the object implementation, it is slow..." Walter, that is not an argument - that is a conclusion - one which you have not provided even a single fact to allow one to draw that conclusion.





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

Evidence I did what?

>
Nonsense! ADO itself does not support a single bit of SQL on the retrieval side.
>

Sure it does. I can use sql in an ADO Command object. If you are talking about running sql against data already retrieved - why would I do that? The primary philosphy behind client/server computing is to only bring back what you need to the client. If I want to locate specific data on the client - I can absolutely do that.


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

ADO has a DML. How it is implemented is irrelevant.


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

Where did outlook come into play? How about objects that sit on relational data??? Now you are trying to cram outlook as the basis of your opinion?



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

Comparing apples to oranges??? Its you doing it once you brought Outlook into the mix.

I'll start looking at this seriously when you have crafted some solid arguments to back up your claim. In the meantime - I'll classify your stuff as part of the "if it is not Fox...its crap" category....