Peter,

>>>No, didn't feel that way at all, Peter. I was just trying to underscore your point. One of the things I'm doing right now is porting old code to SQL Server, so I'm acutely aware of all the differences.< g >
>
>>There you go again. Why do you keep forgetting that I was NOT referring to a SQL Server interface in any way, shape or form???????
>>
>>Jim
>
>
>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.

Of course we will only know once we have it to use.

Jim

>
>IMO this is a perspective, or ?