VFP does have a fatter presence than VB, no doubt....but VFP blows VB away in business functionality....in this day and age, a 4MB runtime as opposed to a 1MB runtime is largely irrelevant. It really pains me to see people defect from VFP as a front-end, often a total, solution. I have seen many situations where VFP would have been the be-all do-all tool but a consultant or staff member suggested a VB->MS SQL client/server solution that ended up 3x the expense and 10x the speed.
>
>VFP does not beat VB in all client/server situations >BUT< ... ya know what? The entire world does not have to be client/server....lets not try to square-peg:round-hole the whole world into c/s solutions. Dammit, I have some FP and VFP solutions running fine with 100's of users that are not client/server and DON'T NEED to be. Client/server is an overused paradigm.....
>
>I can do a soup-to-nuts VFP app that beats VB-SQL c/s solution any day of the week....and it'll beat that combo in the areas that are important to users....responsiveness, low maintenance, et al.....it's time we started concentrating on business solutions and less on fitting solutions to (sometimes) inappropriate topologies simply because they are en vogue.


Hooray!

Oh it does lift the faintest of hearts to see there are others who realise that Client/Server isn't the *only* option. Even if saying that developing client/server apps gives you more kudos in the pub < G >

Speed is the key - as the Sugar Cubes put it. I like responsiveness but I will go with a Client/Server solution *only* if I feel it is the right thing to do.

Cheers
JR