>>>>>>>>>>>>>>>>>>>>>>>
I am usually pleased with the performance of VB on the VB apps I have worked on. But I can think of situations were certain parts of some of these apps would have performed much better if these parts were delegated to VFP DLLs, (like ome very heavy data and text manipulations, aggregation, etc.). But it is often difficult to get clients past the negative VFP rumors.
>>>>>>>>>>>>>>>>>>>>>>>

I't something I struggle with in my consulting work, and there's no easy answer. On the one hand, they hire me for a professional opinion of how to proceed, including of course which tools to use... on the other hand, they are signing the checks, and I can actually understand their concern, which lately has more to do with finding future VFP maintenance/enhancement staff than it does concern over Microsoft's support. It depends on the client -- most recently I had a guy tell me that if he signed off on the VFP side of what I wanted to do, and there was *any* delay in the delivery, it would mean his head (due to the unorthodox selection of a tool). I offered to join him in his lobbying efforts, explain the pros and cons to his bosses, but his answer basically was, don't even bother - he'd take data slowness over a risky decision. That left me with the choice of taking a high priced contract with VB technology alone, or walking away in protest.... guess what I did (<s>)!

Of course, this problem in business goes beyond VFP vs. VB. Luckily, smaller clients have less problem -- I have much more trouble when my contacts are ten layers down the hierarchy ladder. (Remember the old saying from the 1980's --"No one was ever fired for buying IBM"? That attitude may be irritating but those jobs do pay the bills).