Hi Roxanne,
>Doug,
>
>>> So while in theory, the argument could be made that VFP can provide all 4, is it practical? I think not.
>>
>>Indeed, but that wasn't my point. (snip)
>
>>However, for the smaller business I'd think that it might be eminently practical to start with VFP on the back end and then when able to migrate to SQL, for example.
>
>Practical for who? For us as the developer, yeah sure because fox has everything under the hood. But if being practical, cost efficient, and relatively easy to maintain for a small business is the utmost concern here I dont think fox is that practical for the layman for several related reasons:
>
I didn't see any suggestion that VFP was to be used by the small business itself in an efficient... etc. Surely the suggestion is that VFP is a suitable tool to be used to address the business requirements.

>- Fox developers are a lot harder to come by. Your on a well deserved 2 week vacation and something dies, client will most likely be might hard pressed to find another fox person quickly and painlessly.
Pretty lame arguement, given that very few systems, require only tool set knowledge, I work for the treasury middle office of a large investment bank - the best VFP developer in the world could not walk in tommorrow and be productive - there is a big learning curve. Sure they might be able to fix idiot errors like data type mismatch, but those are not typically the errors that need to be fixed. And if a small firm takes on a one-person-band development company, what level of support are they expecting?
>
>- where's the beef? uhhhh I mean server... I'm gonna guestimate and say maybe 1 out 50 commercial web hosting services will let you set up an inexpensive account on a shared server that uses things like fox and west-wind that they've never heard of. But most likely your only choice will be a dedicated server account and/or put your own server inhouse. Both of which take us well beyond practical costs for the small business. Plus if your server isnt inhouse, not likely that something will go wrong and the average hosting service tech will even recognize it like they would with more commonly found technologies, so we're talking 24/7 support for the fox developer.
Is a small business really going to expect the (singular) fox developer to provide 24x7 support? They get what they pay for!
>
>- ideally if the small business goes to the expense to build something n-tier, their purpose is gonna be to expand their business and make more business. So ok, the n-tier project you do in fox in a big success, the client business grows and 18 months later they have a slew of new concerns: more data, more features, and hey what about security? All of which is gonna mean more money for specialized developers that are hard to come by to begin with.
IMO there is no such thing as a finished application - business requirements are constantly changing, thats why we are all still employed. As someone recommending solutions to a business (of any size) one is responsible for advising in a professional manner, highlighting deficiencies, limitations, etc. and lets face it, these are present in all systems.
>
>So is fox practical for small n-tier implementations? I dont think so, unless you have your own internal fox shop to support it. Besides show me an n-tier project that's 'small' anyway. I think fox is practical doing what it currently does best - client server data munging apps. Does it have a place in the bigger picture? Sure, the fox team has got us to the point where fox plays semi-well with the other kids but unfortuantely it's greatest strengths (internal db engine) is also it's greatest drawback when it comes to the n-tier field in general and for an organization that does not have it's own on staff fox developers inhouse in my opinion.
Again the support issue is being used as an argument against the use of VFP, rather than any inherant limitations that VFP might have. IMO combining extraneous issues (support) with a discussion of VFP's suitability for any use does not lend itself to cogent argument.
Regards to all,
Houston.