>
>Clearly, you don't get the point. O.K. another example: if I want to run a report out of this, I don't have to put it in a cursor. I can use the data right away. There is no need to copy the data into a cursor. One performance gain is that the reports prints right away after I set the DE, the other is that won't lose much time evaluating the relations during spooling, So not only a user gets direct reponse when hitting the print report button, but it also finishes sooner than using a SQL generated cursor.
>

The logical results of a query should be dumped to a recordset, either an ADO recordset or a VFP cursor... For you to suggest otherwise, is well, a bit non-standard....


>You need to reboot the machine because after each SQL-command VFP stores information about the query on OS level. Running it a second time produces unreliable results comparing it to the real world when using tables in a multi-user environment.
>

I understand that. The fact is, I did'nt reboot in either case, therefore holding that aspect of things constant.


>Since this whole wish is based on the SQL-select command, and don't have any arguments about the SQL-insert command, I would not object. You could also use a COPY TO FIELDS ... FOR command wich is probably a lot faster (for larger resultsets anyway).
>

Oh, so you only have arguments with some aspects of SQL. I thought your argument was x-base vs. SQL Implementations.. That is the title of your thread.....


>John, don't act stupid, I know you're more intelligent than that.

You know, I should slam you here, but I won't. Gee Walter, talk about getting personal here... Being a little hypocritical, aren't we???

>I don't know the config of your hardware, nor do I know other circumstances of your test. Is it the first time you execute the query or was it a second time ?
>Did you try the xBase eqiuvalent ? Your test isn't saying me anything.
>

It was the first time. Tell me, if my tests don't say anyting to you, why should your tests say anything to me. The point I am making is that the tests themselve don't prove anything. Remember, it was YOU who started this whole testing thing. If you don't like the results, then don't start the discussion. The fact is, I illustrated a few problems with your testing criteria...

Bascially, I took your stuff, fixed it up, and did something that was a bit more reasonable. And, I then extended it to SQL-Server. I can't help it if the results don't happen to support your theories...<s>....


>IMO it is that you don't WANT to see the theoretical benefits, and try to convince me (or moreover others) that your practical approach is supporting your standpoint. Wake up john, important projects are build up out of the both of the two. I won't doubt your practical knowledge, but your theoretical side seems to be far from your practical level. I'll suggest to deepen yourself into the relational model by reading books from either CODD or DATE.
>

Yea, I know what you are saying. The next time I deal with a problem, I'll be sure to tell the client that while in reality, things are slow, in theory, they are very fast. Yea, that will work just fine....

You are right, theory and practical knowledge must work hand in hand. I however, will not let thoery lead me around by the nose, when I know in reality, the facts tell me otherwise. Remember, reality drives theory, not the other way around. You continually stress theory, with little practical knowledge. There is no convincing you otherwise. So lets just drop it. You threw out some data, it got thrown back in your face, and you don't know what to do. I am sure your thoeries and you will be very happy together...