>>Jim, I don't want to interfere here, but as I see it, we all agree, and I think George is making clear here that the logic of "old" code can't remain the same once a remote DMBS comes in order;
>>I think we all agree too about the fact that program logic CAN remain the same, but with huge loss of performance. But, who really tried this ? and if it does, how bad is this really ? I mean, our app was running 15 years ago under FoxBase and 12 Mhz desktop on 33 Mhz server, supporting 20 users with fair response. yes, this was much much slower than today of course, but it was fair anyway. So what if we loose -let's say- a factor 4 on general response ? we have a drawback from 1 Ghz to 250 Mhz. Well, wait a year or 2 and we are back again.
>>So even that way of working will not so much be a problem, and when we could agree upon this, we all agree for sure.
>
>While I agree that there is generally a performance hit with any 'server' style implementation, I feel quite strongly that VFP's present design offers opportunities that may offset much of this in a 'server' deployment.
>It is for this reason that I included as a 'benefit' increased opportunities for applications using a WAN.

Jim,

I sort of feel that maybe you don't quite see what I mean (and therefore George is harder to understand); forgive me if I am wrong :

Where I say that without changing program-logic there will be a performance penalty for sure, I'm not talking about SQL (DBMS) being slower by nature or so. It is my opinion that this may be 100 (or even more) times faster, depending on what one does. However :
What I am referring to, is the fact that when in a loop (maintaining program-logic) for example a Seek is replaced by a SQl Select, and this loop by itself reads 10,000 records (thus implying 10,000 Skips as well), for 20,000 times a SQL command has to be formed within the server, and THAT is where we loose.
Okay ?