>---- snip
MB>>
MB>>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
>
JN>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!
>
JN>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!
JN>^ of the tables regularly hit the 2-gig limit, forcing regular "archiving". Tables totalled 35 gigs (exclusive of archives).
>
JN>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.
JN>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.

Slow down, Jim. I never said that VFP couldn't handle the load. What I said was that applications which require features that VFP does not have could go to SQL Server without the huge investment that people think it is. There is a bias against the idea of using other applications like SQL Server. That's what I am trying to address.

I have been using VFP for huge databases and table for years. I do not need to be convinced that it can handle large amounts of data. However, an application with 500 users banging on a system with high volume will frequently go into a C/S environment. SQL Server and other products of that ilk do have functionality that VFP does not have which is useful in these situations.