>We sometimes speak biased because we don't know other tools than VFP. You will be ofcourse singing in a different tune if you know how to develop real world application using purely DELPHI. The VFP data engine while fast enough is not reliable.

Not reliable? More FUD. It's easily as reliable if not more so than the BDE. I have personally developed Fox apps using native DBFs with over half a gig of data. Others have done even larger apps. Continual DBF corruption more often than not is the fault of poor programming practive and/or bad network design - bad cabling, inferior hubs, poor server configs. And anyway, if you don't like it you can always use SQL Server, and in more ways than one (RV's or SPT). This can't POSSIBLY be considered a negative compared to VB, you have to do the exact same thing! Data HANDLING commands and functions put VFP head and shoulders above VB.

>
>Uncertainty of VFPs future scares a lot of developers and sometimes customers are who quite informed with software development stuff. How many deals we won't be able to close because certainty issues? Many...

Informed? Maybe, but in my experience these so-called 'informed' people aren't 'informed' about anything other than buzzwords. Hard to overcome, I agree.

>
>>If you're really open minded, you won't regard VFP to be a deadman walking.
>I could be wrong ofcourse but the trend shows otherwise.

2 years ago we did NO application development at my company. I was busy working on Citrix and other neat stuff. Today, I am working on my third VFP app for the third client we are developing applications for. Another is unsure of using off the shelf or a custom app, but the off the shelf app they are considering is written in VFP. All three have been exactly the same - they have a job they need to get done. My highest level of proficiency is with VFP. App is done in VFP, end of story. Two of them mentioned VB during initial meetings. I said I would probably use VFP. They didn't bat an eye.


Randy