>>Example, you did imply that SQL-sever will be the winner when a query with big tables involved compared to VFP. I gave you some points on which this IS not the case.
>Imply, or stated in no uncertain terms that this is always the case.

You did imply this.. that is just as worse.

>Sounds like a subjective statement here Walter. Fact is, you made some rather sweeping conclusions about SQL. And, in one of your latest posts regarding SQL, you stated something on the order of the faults with SQL in VFP have to do with SQL itself, not the VFP implementation.

Yes, and I did explain why. It makes copies of data, it doesn't use the data itself, other than in the FILTERED SQL -SELECT case.

>Well, this is wrong, like much of what you ahve been posting.

I'll take that as a subjective statement of yourself john, whether you're not intelligent enough to understand my standpoints or don't WANT to understand them, I'll bet it's the last one.

Every time I say something about your posts, you'll take that as a attack thinking that I'm saying the opposite (as the large query on a WAN case). If you'll review this post you'll see that i'm only arguing the completeness of your statement:

I did never say that you cannot develop database programs within VB
I did never say that xBase is superiour under each cirsumstances on the WAN.
I did never say that I was a Pureist
I did never say that you can't make middle layer components without inheritance.
I did never say that I have as much experience with SQL-server as you do.

And I still had to express this explicitely because you didn't get the point.

>However, we do agree that at times, the x-base constructs with xbase data are often better than SQL. This should not however be construed as a general knock against SQL. Rather, it is a knock against the VFP implementation... Lets not talk about joins with more than 4 or 5 tables.....

>>As for the current discussion, you did state that replication creates too much complexity. To me this only occurs in a specific situation where users a connected from many different remote sites (WAN). In an environment where a SQL-server is locally available (LAN) this is not likely to occur.
>
>You see, you super-impose every situation with WHAT YOU CURRENTLY DO. I on the other hand, raise the bar a bit with more complexity. I suspect that is something you flat out don't handle all that well... Sorry...

I could say the same about you. You said that it creates complexity, which is ONLY the case in YOUR LIMITED SITUATION. Just saying that it creates complexity is what I call an incomplete response. I wonder if you really thought about the possibility to use replication in LAN environments before I mentioned it.

In my case there is a local SQL-server available which makes it possible to use replication quite easely.

>>We've discussed about wheter DML operations are natively or not, inheritance on the middlelayer, etc. In all cases are examples to find where you where either not complete or inaccurate.
>
>I already addressed that I was mistaken in not thinking that SELECTS were not part of the SQL DML. Get off that train Walter....

I was also refering to the VB side. I did never see you admit that VB isn't a DBMS language.

BTW my train just left 5 minutes ago.

Walter,