---- snip
>
>The significance of an investment is not just in the cash spent but in relative value. Some things are "cheap at the price". If you have a client with 500 users banging on a single application, you are not going to want to use VFP for that anyway (on the back end, I mean). Base costs of 5 - 10K are cheap in IT terms. Unless we are getting into redundancy issues (which are not SQL Server specific), that's all your talking about. Can the licensing be expensive? In outlay, perhaps. If I have 500 people banging away at an application and I have to spend $130 per workstation that might seem like a lot. However, if I amortize it over the life of the application, factor in the additional features I am getting, etc. it may not be all that bad.
>
--- end snip

And who's to say you are not going to want VFP for that app anyways??? What would be your rationale for this??? That it can't be done *might* be a reason, but that would be about the *only* reason I could see!

You see (and as I mentioned in a prior note to you on why I use VFP), I once was responsible for a single-app which averaged 250 (peaked at 350) users connected on a LAN from two different cities and it was all FPD! And there was plenty of room for more ternimals in terms of performance!
^ of the tables regularly hit the 2-gig limit, forcing regular "archiving". Tables totalled 35 gigs (exclusive of archives).

So you see, your flip statement, which is the basis of your argument, is incorrect. It *can* be done all FP and it was wanted to be done all FP.
Now if you are suggesting that VFP couldn't hack that, then *ANOTHER* thing we need is for VFP to return to the capabilities of the (former) FPD/FPW - not to go backwards to lesser capabilities.

In case you are wondering, that shop never went to VFP because its assets were bought by a shop using AS/400, so the data was transferred to that system.

Regards,

Jim N