John,

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

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

I just wanted to make sure we are talking the same thing here and prevent you to find an escape here.

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

Of course, anyone who disagrees has to provide proof. Anything you say ofcourse is self explanatory and does not need any foundation, explanation or proof at all.

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

Your OPINION, I've given valid and arguments based on facts why ADO.NET is NOT a dabase engine. That is because it is lacking a DML (or at least something that is worth calling a DML). It merely is a datahandling class for remote data, with a very few properties and methods which you want to classify as a full featured DML.

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

You countered my argument by arguing to someone else by saying ADO.NET is a local database engine. By your own rule, you need to prove it.

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

DBF is not a storage mechanism, it is a storage format. How cursors are handled in memory (They don't neccesarely are stored on the HD) is irrelevant as it is not visible to the user.

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

Tss... You're totally missing the point. 'Relational' refers to the relational theory, not to a relation between tables (e.g SET RELATION). In fact in the relational theory you would decribe a relation as a table. You'd better know what you're talking about, to argue these kind of things. You do not seem to have to knowledge about the definitions of the words 'relational data' nor how this differs from object based handling, nor you seem to be able to see how this translates into a object oriented database and relational databases. You'd better read at least some material from C.J. Date or E.F. codd to see what "Relational" means. Furhter I'd recommend to read some hard core magazines which describes the differences between OO databases and relational databases.


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

Again, your understanding of what relational data is, is seriously flawed.

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

Though I admit that I did not carefully frased the question, you're aiming on passing the resultset through ADO to a seperate backend like SQL server and process it like there. But this is not what I meant. ADO itself is incapable of doing this. It has to rely on a real database engine like SQL Server. The ugly thing is that ADO itself is not able to QUERY opun the data it is storing.

Appart from the problem that it is backend specific (not every (R)DBMS supports ADO recordsets). It totally undermines the goal of a LOCAL dataengine: Process it locally. In stead you've got to upload the two datasets to the server and download the results again (Talk about network bandwidth waste). Again this is a perfect sample of ADOs' shortcommings.

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

I can't see why datamuging through collections is easier than a SQL statement like:

SELECT .... FROM LocalCursor1 LEFT JOIN LocalCursor1 ON ... WHERE ... EXISTS
 (SELECT ... FROM LocalCursor3 WHERE ... ) GROUP BY ... INTO CURSOR LocalCursor4

Implementing this with ADO, would either:

1. Uploading 3 cursors to SQL server, process them there and downloading the result. In this case you use SQL server as a database engine rather than using ADO.

2. You'll have to write a page of code to perform the same action with object based storage. This has the disadvantage of: Hard to programm (compared to the above) and debug, Hard to read and slow. IOW just CUMBERSOME.

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

The facts are not delivered by me. There are numerous published articles saying this. Just read hardcore DB magazines and you'll see plenty of evidence that handling OO data is more cumbersome than relational data. This is exactly the reason that OO databases did not make it breakthrough in the late 90's and 95% of all data stored is stored (more or less) relational. In the DB world there is a consensus that though database applications might be written in OOP, the handling of the data still stays relational. It does not make sense at all to handle the data relational on the backend, convert it to OO at the client for it's GUI and convert it back to relational when updated. OO based database engines do have the tremendous disadvantage of not having a standardized DML. In the case of ADO there is nothing worth calling a DML at all.

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

Understand.

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

It is just a string. ADO itself is not aware of the SQL command. If there was something like a ODBC interface for retrieving HL7 data, you could also pass HL7 strings. ADO itself does not have a clue about what it is passing.

>If you are talking about running sql against data already retrieved - why would I do that?

Data munging and post processing. This is what I'm all talking about. This is the task of the local dataengine: Post processing data.

>The primary philosphy behind client/server computing is to only bring back what you need to the client.

Absolutely. And exactly this point makes a strong case for a local database engine. Retrieving data in the most efficient form and mung it into some form that the client uses to fill its GUI, as food for reports, as basis for META data. An example from a project I'm currently working on:

Two tables:
1. Roster definition. For each rosterable entity, the start and enddate, the start and endtime in which you're able to book appointments, and the timeunits of each rosterable item.

2. Appointments. The appointment for a client for a rostered entity on a specific time.

Goal: Build a cursor (table) which gives you a column for each rostered entity and a row for each timeunit on which an appointment might be present.

Appart from that you've got to build a cursor for each time unit (9:00, 9:05, 9:10 etc) you need to do a lot of datamunging to represent the user what he needs.

In the case of ADO you're faced with a task which is by far more difficult to implement as you've got to iterate through collections use intermediate resultcursors since you do not have the proper DML to process SQL queries on the LOCAL resultset (Withpout passing it to SQL-server again) Of course you can process all on the SQL server which lacks strong record oriented approaches to do the task efficiently and are wasting valuable (CPU, Memory, I/O) resources on the server.

These kind of tasks are very common for VFP applications and extremely powerfull : Post processing data. I guess you totally underestimate this aspect because you simple do not take advantage of it. In data driven applications such mechanism is a MUST.

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

It takes more than filtering and sorting to have a DML. ADO too much requires external database engines to do specific tasks. For the same reason we cannot call ODBC a database engine: It is just a layer in the stack.

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

Read my post previous in this thread about the outlook example. Outlook provide a way to get at its data in an OO way: through its object model. As I previously stated this is very cumbersome because you've got to iterate through collection to find what you need. The filtering capability is a the least slow and painfull. There is no other way to get at your data. OUTLOOK does provide you with a OO 'DML' to get your data. Compared to the relational approach it is very slow and cumbersome:

SELECT * FROM Outlook_appointments WHERE apt_date BETWEEN DATE() AND DATE()+7

If the above would be implemented and the result would be returned in for example XML it would be a real big improvement, not only in performance (Only one call to the COM object), but also in
terms of programming (lines, time and debugging)

Bottom line: The relation between ADO recordsets and OUTLOOK is that they both store the data in a OO way. The outlook example perfectly outlines the problems with handling that data in a OO way.

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

To some up:

In this thread you proved:

1. You do not know anything about the capabilities of VFP 8 (GROUP BY behaviour change, VD improvements)
2. You do not have a clue what "relational" data is supposed to mean.
3. do not see a value of post processing data with SQL or other advanced DML, while this exactly is the perfect task of a local database engine. Therefore you don't seem to have a clue about data driven applications.
4. You don't know the difference between OO databases and relational database and why the OO database is cumbersome to work with.
5. Cannot make the distinction between "Supporting SQL" and "Passing a SQL string"


John, you seem to be a practical guy, but it takes more than that to design proper software. You stated you've been involved in some large projects but I seriously beginning to wonder about the designs of such projects. Just take my advise and learn from this. Buy a book about the relational theory and read it, subscribe to a hard-code DB magazine and read about the difference between OO and relational, look at ERP/ERM packages and see how they handle META data and how they process data in different layers. Look at for example in an appointment system at the data structure and look how the data is transformed for filling its GUI or reports and then see at what levels you could optimize this to reduce network trafic.

Oh, yeah. Just learn about VFP8 features before you draw an opinion on it. You don't have a clue about what you're talkign about.

You've always been the guy telling other people what they should do. I'll tell you to learn more about the background of technologies before you talk someone else into something else by using arguments you don't have a clue about yourself.

Walter,